BI 



INTERNAL MAINTENANCE SPECIFICATION 



FORTRAN V5 



PROPRIETARY INFORMATION 

This document is part of a software product which is the 
property of Control Data Corporation and is proprietary to 
it. Distribution is restricted to customers having a valid 
license for the use of the software product; use and 
disclosure of information in this document are governed by 
the terms of the license. 



77987506A 
0148P-0030A/0103P 



CONTENTS 



B2 



Section AS Overview 

1.0 Compiler Structure ......... .......A- 1-1 

2.0 Global Data Structures .............. A-2-1 

3.0 Comdecks ..................... A-3-1 

Section 8. Deck and Routine Descriptions 

1.0 ]^ xt » «... - B-l-1 

db . J> III ^a# > « I .................... BfcJA fc_ 

1.2 CMPLTXT B-i-7 

1.3 CCGTEXT .............. B-l-8 

2.0 Cradle Routines .......... B-2-1 

2.1 FTN B-2-2 

2.2 UTILITY B-2-5 

2.3 PUC B-2-8 

2.4 Linkage Decks ......... B-2-11 

2.4.1 GCGLINK B-2-12 

2.4.2 CCGLINK B-2-13 

2.4.3 ZEROLNK B-2-14 

2.4.4 RLINK . B-2-15 

2.4.5 LISTLNK B-2-17 

2.5 PEM B-2-18 

2.6 ALLOC B-2-20 

2.7 Snap Interface Routines .... B-2-23 

2.7.1 FSNAP ...... B-2-24 

2.7.2 CSNAP ..... . B-2-26 

2.7.3 RSNAP B-2-27 

2.8 IDP B-2-28 

2.9 Initialization Routines ............. B-2-37 

2.9.1 INITOO ... .......... B-2-38 

3 Q a TMTTIft D-3-/)1 

Q. ■ i7.t il^li I 1W • . . . a . . . . a . . . a a . . . . . . . B"fc""'Tl 

2.9.3 INIT20 ............ ... B-2-42 

2.9.4 INIT21 ........ B-2-43 

2.9.5 INIT22 B-2-44 

2.9.6 INIT23 B-2-45 



3.0 Front End Routines »■•«.. .......... B—3~l 

3.1 FEC - . B-3-2 

3.2 FERRS ................ B-3-9 

3.3 LEX ............ .... B-3-12 

3.4 1-EADER B-3-82 

3.5 KEY .......... B-3-85 

3.6 CDDIR B-3-91 

3.7 DATA B-3-93 

3.8 DECL B_3«39 

~* ^V "»»V #*•%*•• _ _ . . 

■3 • » « • I W . . . . . . . . . . s a a a . . . . . .c a a B""*3 — * 1C/Q 

3.10 FMT B-3-108 

3-11 10 B-3-113 

3.13 CONRED ............ ... B-3-149 

3.14 STMTF B-3-156 

3.15 LABEL g-3-157 

3.16 FSKEL . B-3-162 

4.0 QCG B-4-1 

5.0 Rear End Routines B-5-1 

5-1 REC b-5-2 

5.2 RERRS ....... B-5-4 

5.3 FAS B-5-5 

5.4 MAP ...... ..... B-5-22 

5-5 LIST B-5-36 

6.0 CCG B-6-1 

6.1 CCGC B-6-2 

6.2 CSKEL B-6-8 

6.3 CCG Routines B-6-9 

6.4 BRIDGE .............. B-6-10 



B3 



li 



B4 

A. C&EByiEW 

This section is provided to give general information about 
F7N5. It is organized as follows; 

1. Compiler Structure. 

2. Global Data Structures. 

3 . CurDECKS - 
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The FORTRAN 5 (FTN5) compiler consists of four 
optimization levels (OFTO, 1 ,5,3) divided into quick mode 
(QCG) (GPT=0) and optimized mode <CCG) (0PT>0) , QCG and 
CCG utilize a common front end ( lexical , syntactic and 
semantic analysis) , but have distinct code generation 
mechanisms- A common rear end (assembler , binary output * 
object listing, map and cross reference listing) is used 

The common front/rear end processing with distinct code 
generators is impiementec! as an overlay structure* The 
FTN5 overlays and their principal contents are shown in 
Figure 1. 

Note that the entire QCG mode compiler is included in the 
(0,0) overlay. The (1*0) overlay (also containing the 
entire QCG compiler) is loaded when QPT=0 is requested but 
O bject listing and/o r map listing^function a r* rpqi tippd n r 
when intermixed COMPASS assembly is required. If 0PT>0 is 
requested, the (2,0) overlay is loaded, followed by 
successive loads of the (2,1), (2,2) and (2,3) overlays 
for each program unit encountered. Intermixed COMPASS 
when 0PT>0 requires a reload of the (2,0) overlay. 

The compiler can be split into logical functions, 
reflected in the overlay structure. The functions are 
cradle^ front end, QCG, CCG, rear end and frame. These 
afr*T"des"cr i bed below. ~ ' ~ 

FTlsB source code resides on an LPDATE PL. 



A- 1-5 



B6 



+- 



$ 






System Communication Area 



COMPASS Communication Area co^Pco ^ 
FTN 5 Resident Section 'tTaJ 



t-t 



Cradle 



• - i i i 



! Front 
J End 

+ + 

! GCG ! 

+ — — + 

End ! 
Processor \ 

and ! 
Assembler ! 

,._— <^4> — — — — — — — — — A 

CC ! 
CKR ! 
and ! 
Init ! 
+-—rt + 



(1,0) 
Cradle 

Front 
End 

+ 



iH). nnz> 



Source Input and Output Buffers 
(not in SCOPE S) 



■+-+■ 
i 



•+-+■ 



(2,0) 
Cradle 



QCG 



End 
Processor 

and 
Assembler 



MAP/LIST ! 

+ + + 

Re-!Buffs 
Init! and 

+ fTbls 

+ ^+ 



i (2,1) ! 
! Front ! 
r End ! 

+- + + 

! ! Buffs 



!Init! and 
! !Tbls 
+ + + 



(2,2) ! 
Buffers ! 

I 

CCG 
Code 
Xf ormers 

+ + 

! Bridge ! 

+ + 

! Tables ! 
+ + 



, A ir> 



! (2,3) ! 
! End ! 
'.Processor ! 

+ set rrsf*- - 

! MAP /LIST i 

+ + 

! Assembler ! 
+ + 

i Buffers ! 

+ — r + 

-/ 



COMPASS 



+ + 



/i b yV-' : ' '' 
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LINK: 
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The cradle consists of support routines which are 
used by all overlays. Included here are 
routines/functions which are present in some form 
for all or most overlays. The following decks are 
included: 

Tables and cells which survive overlay loads. 1^-} ■ o£ <■■. 
Overlay processing routines. Lokhtji. fc£i£ /oJL~/„ K " f ' : r '" 

General utility routines (mostly comdecks) for, 

conversion, I /O , etc. olP ?l. Cf* * C 6 A fr c rO OJ ; "• < S ■ 

... _ .. .. . fi^S/* , ..„,: C^ r 

tme f% #% f% g* SHI a 1 ^6 % TP m^ *■% V^ ^ W rf^ i 2 «5a #% 1 ** 9%. I «, ^» ^% «■% ••» M ,*■% I a ■ ,m .*» «ifc ,«* mm. *m* i i ■■' /""*«" W~£~> * &t*r jT *»>■* V 

* t wg i €i*fi ui • a w ww«i4»iw.b<l.d» i C3W J. C W Ul I Ul U* A VCUlUI^tf L v ~ '''■■" *\~ ~s 

global cells, control routines, file closing, fi^c_n>^ i^rncff 
statistics. <_^ _ ,„-., „t A -*>,,., , . ,... ,-; .< , o^*rr^7 DCc ^ 



^wj 



rew f >+■ .>. ,tf S 6 y .^ £A~Y £/- *V A'''/ f : 



* ; > s 



r*«L * 



Routines to support common front/rear ends. 
Provides stub routines for functions not required by 
one of the code generation modes. 



GCGLINK : 


(0,0) 


and (1,0) overlays 


CCGLINK : 


(2,0) 


overlay 


zerqlink: 


(0,0) 


overlay 


RLI!sft< : 


(2,3) 


overlay 


FLINK : 


(2,1) 


overlay 



pem: 



Print error messages. Routines to output diagnostic 
texts (not the texts). Not present in the (5,2) 
overlay. 



ALLOC 



Table management and allocation. Not present in the 
(2,2) overlay. 



SNAP: 



Test mode only. The snap formatting and IDP 
interfaces. 



FSNAP 
CSNAP 
RSNAP 



(0,0), (1,0) and (2,1) overlay 

(2.2) overlay 

(2.3) overlay 



IDP: 
Init: 



Test mode only. Interactive debug package. 

Each overlay (primary and secondary) contains an 
overlay initialization routine which performs the 
initializations required by that overlay. 



INITOO 
INITIO 
INIT20 
INIT21 
INIT22 
INIT23 



(0,0) 


overlay 


(1,0) 


overlay 


(2,0) 


overlay 


(2,1) 


overlay 


(2,2) 


overlay 


(2,3) 


overlay 



All initialization routines are used once per 
overlay load and the space they occupy is free for 
table usage (or whatever). 
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1.2 Front End 

fec: 

FERRS: 
LEX: 

key: 

cddir: 

data: 

decl: 

type: 

fmt: 

io: 

par: 

conred: 
stmtf: 

1 apc;;, : 

fskel: 



The front end routines provide lexical * syntactic 
and semantic analysis for the FTN5 compiler. The 
following decks are included: 

Front end controller. Main control routines for the 
front end, front end global cells and tables? table 
s ea r c h and entry r ou t i n e s . / *J 7 pt A ~ ~ 3 tm 'f' fi^ndc t T#7 1 /yj 

fat X '-/*■■'«?£*- P N 
Front end diagnostic texts. L&iStrt ,*$& •^tS/Wi tC ^ 

Lexical analysis (scanner ) .^5£cl . u $ j^g- 

Keyword statement processing. 

CS directive processing. 

DATA statement processing. 

Declarative statement processing. 

Explicit and implicit type declaration processing. 

Format statement processing. 

I/O statement processing. 

Syntax and semantic processing of expressions 
{parser ) . 

Constant reduction. Compile time arithmetic. 

Statement function processing. 

C^a-(>afiian4- lakal »J l"\n *- 4. -t 4. MMnMM 4. - ^ .-.— „.«. — 4 — - 
wwa wciiitn t, jl«ww* «ail\J ksw a t.a t.CIHCil C p I " UU C3 3 J. I IS . 

Front end code skeleton linkage to CSKEL. 
(2 y l) overlay only. 
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1.3 QCG: The QCG (Quick Code Generator) routines provide the 

OPT=0 code generation functions- Decks arel 

QCGC: QCG controller. Control routines* cells and tables. 

QSKEL: QCG instruction skeletons. 

FUN: External procedure call and argument processing. 

Dtrr» . n__.:— -i._— _ _ i _ _ j. .: _.__ 

GEN: Main QCG code generation processing. 
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1.4 CCG: The CCG (common code generator) routines provide the 

CFT>0 code generation function. Decks arel 

CCGC: CCG controller. Control routines* cells and tables. 

BRIDGE: Transforms front end IL output to a form understood 
by the common code generator. 

CSKEL: Bridge instruction skeletons. 

CCG: The actual common code generator. Decks making up 
this portion are: 

CGTM: Code generation table manager. 

MIO: Mass storage I/O routines. 

FBV: Form bit vectors. 

GPO: Global program optimization. 

GRA: Global register assignment. 

SQZ: Redundant operation elimination. 

MCG: Machine code generation. 

BDT: Form dependency tree (graph). 

CFA: Control flow analysis. 

UDT: Usage/definition table processing. 

PRQSEG: Process accumulated sequences. 

Output: CCG output routines. 
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1.5 Rear End: The rear end routines provide assembly? binary 

output and end time listing functions. The decks 
are: 

REC: Rear end controller. Control routines* tables and 
cells for the rear end processor. 

RERRS: Rear end diagnostic texts. 

rAPi r— *-v>Tr* Ah. i i_t r> i __i_. Li 

r-f-K3. run i rer-HM dsseinDier. Dinar/ proaucxion, 

MAP: Attribute* storage map and cross reference listing 

o sr* f% rts if t1 firi _ 

LIST: Object listing production. 
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1.6 Frame! A loader interface module. Consists of deck stubs 

which are place holders for the various decks making 
up each overlay. The mechanism by which the front 
and rsatr ends can be truly common. 
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2.0 GLOBAL QflT&-3IBUCILfiS3 Qf 3 

This section describes the data structures used by FTN5. 
Ref erence to tables will be by the FWA ceil CT.xxx). The 
structures described are classified as follows: 

5.1 Global (all overlays and compilation modes) 

2-2 Front end 

2.3 Special structures 
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2.1-1 Symbol Table (T.XYM) 



5 



'■.j? >F' 









1/-0 



fU^H lABi^- 



The FTlvB symbol table contains source symbols and labels and 
compiler generated symbols. There are two basic formats j 
symbols and labels and many subformats* depending on the 
nature of the symbol/label. The symbol table is dense and 
entries occur in the order they are encountered/generated 
during compilation. Access is via hashing and associated 
with the symbol table is table of hash buckets. A symbol 
table entry consists of three words* designated WA. r WB. ? wC, 



£>X —_ .J _ _ J <-».__!_ _ 1 p- L. I ^ _ t_ _ n v 



BU 



U1A 




SYM: DPC (left justified, zero filled) 

NF: Cannot be formal parameter 

HASH: Hash chain pointer (zero if end of chain) 



WB. 




PNT: 
lev: 
base: 

clas: 
cgs: 

LAo : 

mode: 



Pnin+an £ialrl t + «■% T TMM i £. 



T Ml CT 



Level number 

Symbol table ordinal of equivalence class base 

members 

Attribute bits (see below) 

Compiler generated symbol 

Statement label 

Mode (type) of symbol 
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WB 



CLAS B 

sfa: 

1REF: 
MATS 
SAVE: 
NLST: 

lev: 
vds: 
typ: 

AGN; 
INTF 
DEXT 

/■*r— fc.B— 

i. r-i yi- 

LDO: 



bmem: 

locf: 

lcm: 

fp: 

com: 

ext: 

ent: 

fun: 

sub: 

ary: 

eqv: 

parm: 

def: 

nvar: 
var: 



its 



Statement function dummy argument 
One reference (stray name) 
Materialized (storage required) 

Declared in SAVE statement (implicit or explicit) 
group name 

in LEVEL statement (implicit or explicit) 
variable dimension description 
an explicit type declaration 

Anr>T/1kl _ J. _ JL. __ _ _ J- 

nOSXUlN S- Id LfSIHtJI! I. 

INTRINSIC statement 
EXTERNAL statement 



Namelist 
Declared 
Appeared 
Appeared 
Va r i a b 1 e 
Declared 
Declared 



in 
in 
in 
in 
in 



i laim 



Load only variable- Also defined as: 

SFX: used when parsing statement function 

AG02: object of assigned goto 

Base member at an equivalence class 

LOCF function (irreducible) 

Resides in large core 

Formal parameter (dummy argument) 

In a common block 

External name 

Entry point name 

Function name 

Subroutine name 

Array name 

In an equivalence class 

Parameter (symbolic constant) 

Defined (VAR-stored into; SUB/FUN-arg count 

determined) 

Not a variable 

Va r i a b 1 e 



WC, 



--+-+■ 

!/! 

RL!/! 

!/! 

— +-+• 

2 1 



RB 



CLEN 



18 



■+-+-+ +• 

!C!/! B ! 
!T!/! C ! 
!Y!/! P ! 

■+-+-+ +■ 

114 



RA 



24 



RL: Relocation type ~ : ^m s h -xryw "> r,v.^.^ 

RB: Relocation block number J 

CLEN: Character length (per element) 

CTYP: Character type (constant or assumed length) 

BCP: Beginning character position 

RA: Block relative address 
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Special Symbol Formats: (WA. is standard) 
Formal Parameter (Dummy Argument) 
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WB 



PNT 






•'+-+■ 
!L! 
!E! 
!V! 
+ -+• 



FPNO 



i 
i 
i 






CLAS 



-+-+-+ + 

!C!L! M ! 
!G!A! ! 
!S!B! D ! 

+ -+-+ + 

113 



> « ■» • ■ w ^aiiviai u 

LEV: Standard 

FPISH3: Formal Parameter Number 

CLAS: Standard (FP bit on) 

CGS: Standard 

LAB: Standard 

MODE: Standard 

WC. is standard 

Function/Subroutine (except statement functions) 

+ + + +_+_+___ 



MB. 



•+ 
; 

JPF ! ////////////////// 
i 

18 



CLAS 

+ + + + -+-+ 

28 



+-+-+ + 

!C!L! M 
!G!A! O 
»S!B! D 

+ -+-+ + 

1 1 3 






JPF: Index into intrinsic function table (if intrinsic) 

CLAS: Standard (with proper bits set) 

CGS: Standard 

LAB: Standard 

MODE: Standard (only on functions) 




FUNT: Function type 

ARGC: Argument count 

CLEN: Standard (function only) 

CTYP: Standard (function only) 
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CI 

Statement Function 

I ! I !C!L? M 

WB, ! STFP !////////////! CLAS !G!A! O 

1 ! ! ! S ! B ! D 

15 12 28 113 

STFP: Pointer to statement function definition (on T.STF) 

CLAS: Standard 

wSSli Standard 

LAB: Standard 

MODE: Standard 

WC. is in function/subroutine format 

Statement Label Format 



WA. !//////! STL !///////////! HASH 
i; ii 
+ + + + 

6 30 12 12 



STL: DPC label (right justified, zero filled) 
HASH: Standard 



! ! *C!L! / 

FR ! FMTL r CLAS !L!A! / 

I i i e> i o i i 

+ + + - + - + + 

15 12 28 113 



WB 



FR: Label first reference line number 

FMTL: Format length <FDEF>* in characters 

CLAS: Attribute bits (see below) 

CGS: Standard 

LAB: Standard (on) 



A-2-5 



C2 



WB.CLAS bi 
1REF: 
INDO: 
NIN: 
DLPE: 
DLC: 

lc: 

NDEF: 
LDEF: 
FREF: 
FDEF: 

PRD: 

ni mm _ 

I » w it - 

DLEN: 
DLEX: 

dlni: 

DLER: 

dogl: 

DMAT: 

act: 
ina: 

SLEN 
SLEX 
SDEF 
SREF 
DOT: 



ts 



Stray label 

Label in do loop, loop has exit 

Do loop has (possible) negative increment 

Label is possible do loop entry 

Do loop has been closed 

CCG internal label 

Label defined on non-executable statement 

Label undefined 

Label referenced as format 

Label defined on format statement 

Do parameter redefined in this loop 

■~ww»» hW,n va*na Wfiu.nnai u t/i~<3l il.il 

Loop contains an entry 

Loop contains an exit 

Loop not innermost (of a nesting) 

Loop contains external references 

Generated label for do top 

Loop index to materialize 

Label is active 

Label is inactive (cannot be referenced) 

Entry to a do loop 

Exit from a do loop 

Label defined on executable statement 

Label referenced as executable statement 

Label is a do loop terminal 



•+-+■ 



WC 



RL 



!/! 
!/! 
!/! 

+ +-+• 

2 1 



RB 



LINE 



///// 



RA 



18 



24 



RL: 
RB: 

LINE: 
RA: 



Standard 

Line number of definition 

Standard 
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2-1-2 Variable dimension Information Table (T.VDI) 

One word table entry for each variable (adjustable) 
dimension calculation required- 



C3 



+-+ +• 

VD. !M!////! 
!A! ! 

+ -+ 1- 

2 4 



CA/IND 



IS 



PNT 



lff^N 



LEN 



IS 



ma: 
ca: 

IND 
PNT 
LEN 



Materialize/Allow flags 

Bias for cells (GCG) 

Index of VD. store operand iFE) / 

Ordinal to vardim turple table/(first turple) 

Number of turples 



/ 



JPi «"• 



7 
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2.1.3 Formal Parameter Information Table (T.FPI) 

One word table for each unique formal parameter (dummy 
argument) in the program unit (the master copy for entry 
point parameter lists). 



r-r 



+ -+-+-+-+-+■ 

V!L!V!L!/! 

D i C i D i E ! / ! 

S! ! !V!/! 
! ! ! O ! / ! 
+-+-+-+-+-+■ 

11112 






18 



5USU 



IS 



PNT 



IS 



VDS: Formal parameter used in variable dimension descr 

LC: CCG made local copy 

VD: Used in issued variable dimension 

LEVO: If LEVEL 

LEN: Number of subref erences (FE) 

SUB: Index into subtable (end of program unit) 

CA: Bias of local copy (CCG) 

SUBO: Number of LEVEL references 

PNT: Symbol table ordinal 



A-2-8 



2.1.4 Constant Table (T.CON) UU 

The constant table is unformatted. It contains the binary 
values of converted (or manufactured) constants encountered 
during front end processing. 
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2.1.5 Common Block Name Table (T.BLKS) 



CA. 



The common block name table consists of one (two word) entry 
for each named common block (or blank common) encountered 
during declarative processing. 









BNAM 



LMI 



!H!V! 
! !L! 



BNAM: 

ch: 



lvl: 



lmi: 



zero filled) 



Block name (DPC* left justified* 

Character information 

CHAR: Block has character entries 

NAC: Block has character conflict 

Level information 

CNFL: Level conflict 

BFLT: Level default 

BLFL: Level number 

Index of last member of block in T.CCWI 



CB. !L!S!R! 
!C!A!N! 
!M!V!C! 

+-+-+-+ 

114 






FMI 



TA! 



BLEN 



18 18 18 






LCM: Block is in ECS/LCM 

SAv; Block appeared in SAVE statement 

RNC: Remaining character count before block round 

FMI: Index of first member of block in T.CQMM 

TAG: ECS/LCM pointer tag 

BLEN: Block length (words? rounded) 
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2.1.6 Dimension Table (T.DIM) 
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The dimension table consists of a header wordy and pairs of 
dimension information* one for each dimension. Only unique 
dimension information is kept* so if two arrays are 
dimensioned the same (number and form of each dimension the 
same) only one entry in T.DIM will be made. 

+ + + + + 

DH. ! ATTR ! PS ! RA ! DIM ! 
^ + + + + 

/ ^ ^i\<\^> ft* St* 
/q ATTR: Attributes (see below) T^TAc 

%i<9^ PS: Product of spans (partial product for VD) ft-aiL /V£J1AY t'LyjfC, 
RA: Relative address of runtime dimension table 
DIM: Number of dimensions L*</ ^t\ > n 

DH.ATTR bits 

VD: Variable dimension present 

AS: Assumed size array 

VP: Variable product of spans ■ i( ^~S\ 

MAT: Runtime dimension table materialize p^^K £vP«*+t~- J 



Im 



Art TO t* D2_ , s sc r 

Di. !//////////////////////////!T!///! SPAN ! 

! !D! ! ! 

+ — .. + _ + + + 

30 15 24 



+ - + + + _ + + + 

D2 • ! T ! //// ! LB I T I /// ! LB ! 

!D! ! !D! ! ! 

+ - + + + _ + + + 

15 24 15 24 

TD: Type dimension (on-variable, of f -constant ) 

SPAN: UB-LB+1 

UB: Upper bound 

LB: Lower bound 
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2.1.7 Intermediate Language (T.PAR) 

The Intermediate Language (ID is the internal parsed 
representation of a FTN5 source program. The IL consists of 
triples (historically misspelled turples), each turple 
consisting of a header and two operand words. Descriptions 
of the header and operand words follow: 



TH. - Turple header. This general format goes through 
several transformations? depending upon where the 
operator is in the parse process: 

<-«}• Si a t.wi w«s * St. dCU wui 4113 roi 3CI l-Hia J. 7 3 a -3 



TH. 



o?<^ C SKEL .^» 



+ _ + + + + 



IS 



^ 



1ATR 



+ + + _ + _ + + + 



14 



+-+ +• 

!Qi /// 
!A! /// 
!T! /// 
!R! /// 

+-+ -+« 

4 6 



STPR i TBPR 



9 



Operator Selected During Parser Synthesis 



+ + +-+-+ + + + 



!Q!/! M 

TH. ! SKEL ! 1ATR !A!/! 

!T!/> D 

!R!/! E 
+ + +_+-+— 



18 



14 



MODC 



TBPR 



+-+-+ + + + 

4 2 4 9 9 



Turple output to T.PAR (ID 



TH. 



+ + +-+-+ + + + 



SKEL 



IS 



LINE 



+ + +-+- + + + + 



14 



!Q!C! M 
!A!A! 
!T!T! D 
!R!R! E 
+-+- + ■ 
4 2 4 



1 
1 

■ + ■ 
9 



TBPR 



SKEL: Code skeleton index or relative address 

1ATR: Parse attributes (see below) 

LINE: Source line number (if first turple of line) 

QATR: QCG attributes (see below) 

CATR: CCG attributes (see below) 

MODE: Type of result (dominant mode) 

MODC : Mode coersion(ji '■>v>L'"~* ^D^ 'fa -iffi^ 

STPR: Stack priority 

TBPR: Token buffer priority index 



A-2-12 



TH.1ATR attribute bits: 

NSQZ: Turple is not squeezable 

UNAR: Unary operator 

MDLSS No associated type 

DIS: Operator is algebraically distributive 

COM: Operator is algebraically commutative 

AS: Operator is algebraically associative 

MASK: Masking/logical operator 

CHAR: Character operands allowed 

SPlD: Specific mode determined 

BIND: Operator OK for dimension bound expression 



C9 



NSTD: SKEL field contains routine address 

PLC: Operand is // of passed length item 

1DUC: First operand is register allocated 

2DUC: Second operand is register allocated 

TH.CATR attribute bits: 

PAP: First turple of an argument 
PFP: First PAP of an argument list 

Operand Format (TP.) 



o- 



c» 



ord: 
bias: 

ATTR: 
1ATR: 



ORD 



16 V.*^u 



^V 










BIAS 



ATTR 



24 



13 



Symbol table ordinal of operand (usually) 
Constant addend 
Attributes (see below) 
Parser attributes (see below) 



M i t\{L 



! 1ATR ! 
■+ + 

7 



TO ATTD _4» + m i W. . -*.« U. i ±~ ■ TV.^.,-— . U. - a.^. J — .*. — —_.:_ _ !_._.. -i.i__ r-Mnr\ i 

ii ami i ix ai.i.1 ii/uie isj.i:». nieae wxis ucLCniuiis nun me tjr\l_' ctriQ 



BIAS fields are to be interpreted. 



LCM: Operand is ECS/LCM resident 

FP: Operand is a formal parameter 

EQV: Operand is equivalenced 

GL: Generated label (ORD is GL number) 

ARR: Operand is an array 

SfclBT: Short constant (ORD is null, BIAS=constant) 

ADDR: Address reference operand 

INJR: Intermediate operand (ORD is IL pointer) 6i^S H^^ji^iL^^i 

CAT: Concatenation operand 

IQD: I/O definition 

IOP: Potential I/O definition 
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TP.1ATR attribute bits: These bits are used during parse 

only and are discarded when IL is 
output. 

ARS: Array subscript operand 

ARE: Entire array reference 

LCF: Reference for LQCF intrinsic 

EXPR: Operand was an expression 

MODE: Type of operand (3 bits) 



CIO 



IucEifi-Eoxinals 

Assign turple 

ASSIGN 10 to I will produce 



ASSIGN 



+— ■ 



line no. ! 

+■ 



■+-+■ 
!A! 
!D! 
!D! 
!R! 



ord(10) 



ord(I) 



bias(I) 
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QQzB£ain_IunEl£ 

The DO statement has the form 

DO s i = ml, meU m3 

This statement generates a turple of three triples which contain 
the required parameters for code generation of a DO-BEGIN. 
There are two sets of DO-Begin turples: DOBEGAO? DOBEGBQ, 
DOBEGCO for zero trip DO loops? and DQBEGA1 ? DOBEGB1? D0BEGC1 
for one trip DO loops. 



! DO-BEGA 
! OPCODE 

1 ! 



8 



Line No. 



Mode of 

i 



Operand i 



! DO-END 
! label 







Operand 


ml 




DO-BEGB 
OPCODE 


i 

! 


Line No. ! 

i 





t 
1 






Operand 


ma 








Operand 


m3 




DO-BEGC 
OPCODE 


i 


Line No. ! 
i 





i 
» 


DO-START 
label 


1 
I 















Each operand ml, mH? m3? and i appears in the standard 
Ordinal-Bias format. 

The QQzSI^BI— laiksl is a generated label ordinal for the zero 
trip loop or zero if the loop will go at least one trip. 

The compiler provides both a control card option and a 
compile-time directive to compile DO loops as one trip loops? 
the status of which determines DOBEG op-codes. 

When the label associated with the end of the DO loop is 
encountered the following turple of two triples will be 
generated. 
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PI? 

QQ=Q£=IUkXL£l£ u,t 

There are two sets of DO-END turples, DOENDAO? DOENDBO for zero 
trip Do loops and DOENDAi , DOENDBi for one trip Do loops. The 
trip count is established at DO-BEGIN time. 

+ + + + + 

! DO-ENDA ! Line No. ! Mode of ! ! 
! OPCODE ! ! i ! ! 
+ + + + + 

1 ! Operand i ! 
+ . + 

c : uperana mi ! 

! (if m3 is constant or simple variable* else zero) ! 
+ + + + + 

3 ! DO-ENDB ! Line No. ! ! ! 

! OPCODE ! ! ! ! 

+ + + + + 

4 ! DO-START ! ! 

! label ! ! 

+ + + 

5 ! DO-END ! ! 
! label ! ! 
+ + + 

The presence of Operand m3 is not necessary but may make it more 
convenient for an optimizer to eliminate the copy code generated 
in the prologue <Temp*m3). 



ALi±hmfi±i£=IE-.Iuii£lfi 

The ar ithmetic-IF statement has the form 
IF(e) nl,nErn3 

A turple of two triples is required to represent it because 
there are four input parameters. 

+ + + + + 

! ARITH-IF1 ! Line No. ! Mode of ! ! 

! OPCODE ! ! e ! ! 

+ + + + + 

! Operand e ! 

+ + + 

! Label nl ! ! 

+ + + + + 

! ARITH-IF2 ! Line No. ! ! ! 

! OPCODE ! ! ! ! 

+ + + + + 

! Label nZ ! ! 

+ + + 

! Label n3 ! ! 
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L.Qg.i£al.lE-IunElgs. w I w 

These turples represent 

IF<£)s 

where s is a logical expression and 
S is an executable statement. 

A turple of two triples is used to express this construct? with 
operand-1 of the first turple pointing to the expression and 
operand-w of the second turple containing the generated label of 

lii» i_» ~ JS j^ *"* o "■ JS a^ r*f i l^n "™ S. "T ^ ^ ct ja tt ^ i i~* 4» #** rt «■» ^"" *"* rf*i «* ti <s i iw i\|i its _ <■» 4 w% *• *■». ^Wm 

turple denotes IF (.NOT.e.) GO TO al 

The special case 

If <£> GO TO lafc 

will be recognized and produce an L.IF turple with operand-2 of 
the second triple containing Iafc> 

The special case 

IF(fi) RETURN 

is similar, with the label being at the exit line. 

Special turples are used for logical IF statements of one 
relational operation. The hj-IFqe turples are 6 words, with the 
operands of the relational as operands-1 and -2 (words 2 
and 3). Word 6 contains the branch target. 
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IF(A.EQ.B) C=D will produce: 



+~ 






— + 






! 


R.XFfvSE 




i 


stan da r d 


operator word 














1 








operand (A) 
















i 








operand (B) 
















I 


n Trrnirr 




i 


standard 


operator Word 















not used 



! n ! ! !G! ! 

; I I \{_\ i 

+ + + + . + + 

+ + + 

! R.ST ! standard operator word ! 

+ +«.- + 

! operand (C) ! 

! operand <D) ! 

+ + 

+ + + 

! LABEL ! standard operator word ! 

+ + + + _ + + 

! n ! ! !G! ! 

• 1 ! !L ! ! 



ZF<A.EQ.B> GO TO 10 will oroduce: 



+— 




~ + 






4. — - 


R . IFEQ 


1 


standard 


operator word 


T 
1 

4. . 




T 


operand (A) 










operand (B) 














A— - 


R.IFEG (B) 


1 


standard 


operator word 


















not used 




I 


SYMORD(IO) 


| 






+ — 




~ + 







A-a-is 



This is issued only for a main program- 



CI5 



+ + + + + 

! SEX ! Line No. ! ! ! 

i i 

+ + 

+ + 



Eilfi-.IuE.Ele 

These are issued due to files on a PROGRAM statement and always 
precede the SEX turple. 

+ + + + + 

! FILE ! Line No. ! O ! ! 

I Fi ! BUFL ! ! 

+ + + + 

! FB i MRL ! » 

+ + + 

A 

Where: Fl = ordinal into file name table 

F2 * ordinal into file name table of equivalenced file 
(Fl = F2) 

BUFL = buffer length value 

MRL = maximum record length value 



U2aiaE_QQn±r.fll-Qar-il«iLQC2-.Iuii£la 

+ + _ + + + 

! LCC ! Line No. ! i ! 

! O ! Index into LCC table ! ! 

+ + + + 

! ! NC ! ! 

+ + + + 

The LCC table contains the loader directive image to be issued 
by the assembly phase. NC = number of characters in the 
directive image. This turple always precedes the SEX turple. 



A-2-19 



Hsails£LJLh£B2_InG.Els 



C16 



+ + + + + 

! HDR ! Line No- ! ! » 

+ + +———_+ + 

! SYMTAB ! I 

! Ordinal ! j 

+ + + 

! Program Class ' 

+ + 

Where: S-MI-S-flH_inai is the symbol table entry for the routine 
name. ElL__r.am_£.Iass specifies the kind of routine. 

-QQE-I_r.£lfi 

+ + + + + 

! NOOP ! Line No. ! ! ■ 

+ + + + + 

! t 

+ ; 

+ ; 

This turple signifies no actions. It may be a convenient place 
to put a line number. 



Q-ia-1-.LisiiEa-Qiinir.ai-.I-HEifi 

+ + + + _ + 

! OLIST ! Line No. ! ! ! 

! ! SW ! ! 

+ + + + 



+ + 

Where: SW=1 if object listing is to be turned on and SW=0 if 
object listing is to be turned off. It is issued only 
in response to a CS directive. 
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fifti-£aaaftdJ^mft±h-JLfiELi-IOiiElft " ' 

This turple has the passed length of a type character dummy 
argument or character function as a result. 

+ . + + + + 

! GPL ! Line No. ! ! ! 

+ + + .—+—.+ + 

! C ! O ! ! 

+ 4. 4. + 

! O ! 

+ — — — — -+ 

Where: C is the symbol table ordinal of the dummy argument or 
of CVAL. for a character function. 



SIQE^r_E£U3E-Iur.£l£ 

+ . + 

! standard operator word ? 

+ + 

+ + + 

! base(rout) ! • 

+ — ~~ + + 

+ + + + 

! base(st) ! bias(st) ! ! 

+ + + + 

Where: base(st) is CCON. if a string was specified on the STOP 
statement* or zero. 

bias<st) is the offset in the character constant table 

w 1 hue sr vi j.113 • 

base(rout) is the symbol table ordinal of the entry for 
the STOP routine name. 
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02 

Gam&u±£4_£a.I&..Iu£El£ 

+ -. + + + + 

! CGuiO ! Line No. ! Mode Of ! ! 

! ! * INT<e) ! ! 

+ + + + + 

! Expression e ! 

+ + + + 

! ! # of labels ! » 

+ * + . + 

This turple is produced for GO TO (PI, PB f P3,...,Pn> e. The 
jump turples ( JGOTO) , one pep label in the computed GO TO list. 

EEfcJQ_IU£.£l£ 

This turple is output only when control flows into the END line 
of a main program. 

+ + + 

! PEND ! standard operator word ! 

+ + + 

+ + + 

! base (ex) ! ' 

+ + + 

+ + 

! ! 

+ + 

Where: base(ex) is the ordinal of the symbol table entry for 
the external to be transferred to at program 
uermma uicn ■ ihe code from this turple will transfer 
control to a termination external identified by symbol 
table entry ex. 



A-a-sa 



D3 

Eq±h*_Iuce1£ 

+ _- + __ + 

! ENirY ! Standard Operator Word ! 

+ + + 

! ordinal i ! 

+ + + 

! « 

+ + 

fl£iilnal is the symbol table ordinal of the entry name on the 
BMTRY statement. A link to he formal parameter table which 
contains the formal parameter or list for this entry is in the 
PTRF field of the symbol table entry for the entry name. 

SE£_Iur_£l£ 

This turple indicates the beginning of a new IL sequence, i.e., 
the turple numbering is reset to zero, with the turple following 
the SEG turple being turple number zero. 

+ + + 

! Standard Operator Word ! 
+ + 

i 

+ 

i 

+ 
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IZQ-Iucaifis 



Qfln±cfli^Iu£i£ifi 



D4 



IOCTL 



Standard Operator Word 



Code 



I 
i 

-+ 



Base 



up er and 
Bias 



> v i 

: 1 : 

!0! 

!D! 

•+-+■ 



IZQ_LSU±iQ£_GXiiinal is the symbol table ordinal of the I/O 
routine to be called. The symbol table ordinal is present in 
the first turple received to communicate the symbol table 
ordinal and allow usage/definition information collection in 
0PT=2. 
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05 

Q.Q.&& is an integer specifying the numeric control code of this 
turple. 



UNIT= 


i 


END= 


2 


ERR= 


3 


FMT= 


4 


IOS= 


5 


REC= 


6 


w!\ X I 


7 


IW1L 


e 


ACCESS* 


12 


BLANK s 


13 


BUFL= 


14 


DIRECT* 


15 


EXIST* 


IS 


FILE* 


17 


FORM* 


IS 


FORMATTED 


19 


NAME* 


20 


NAMED* 


21 


NEXTREC* 


22 


NUMBER= 


23 


OPENED* 


24 


RECL* 


25 


SEQUENTIAL* 


26 


STATUS= 


27 


UNFORMATTED* 


28 


BUR 


29 


CNT 


30 


MOD 


31 


STR 


32 


FMTA 


33 



BUFFER I/O fwa/lwa, parity and ENCODE/DECODE string, length are 



ilen in\n1 aman +e» A ^^ mn4-n n 1 4., i —. «. 1 — — 
_ •»» * «r •!««-• i t.wv as wwiiliWA <.ui~ K " 



Q££Lami_BassZQE£nand_Bias designate the operand of the control 
turple (i.e., REC=X specifies X, ERR=10 specifies label 10, etc.) 

Qnd£Lina-a£_QaninQl_Iu£.Rl££ 

The turples will appear inthe order in which their corresponding 
specifiers are encountered in the source. 
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Qa±a_Iu£Ele 



D6 



All IODTA turples for a segment of an I/O list will immediately 
precede the IQF call that processes that segment. 



IODTA 



Standard Operator Word 



!I! 
!0! 
!D! 



Data 
Base 



! Data 
! Operand 



Bias 



■+-+■ 



3 »•>> J. im- 

Operand 
Base 



+ 



! Operand 
! Bias 



Qa±a-fiE£lLailiLii&a£ZBias specifies the data item to be read into 
or written from. 

L£0£±h_o.££HaniLJiaa£ZBia£ specifies the length of the data item. 
A constant length is contained in the bias field and the base 
field is zero. Constant lengths may exceed the length of a 
short constant bu are still indicated by the short constant bit 
being on. In all cases, lengths are in terms of number of 
items. A double precision, complex, or character variable is of 
length one. (Character element length is available in the 
Symbol Table.) 



bl£uz£J2lla£&il2l£_lZQJ^_LaaR£ 

Non-collapsible I/O DO's will result in a normal DO control 
structure surrounding one or more restart calls to perform the 
data transfer. 



IQE-.Iuc.Ela 

Operand 1 specifies the symbol table ordinal of the routine to 
be called. 

Operand 2 specifies the restart routine symbol table ordinal or 
zero if this is the last call of the I/O statement. Restart 
calls are required for situations such as READ (1) I, A(I). 
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In the following example, I is an integer variable, D is a 
double precision variable, and A and B are real arrays with a 
lower bound of one, 

READ <5,20,REC=N,END=10) I ,D,A( I ) , (B( J) • J=l , 10) 
would be represented as 



D7 



1 


IOCTL 




Line No. ! 


i 




1 


IRI 


i 


UNIT Code 




i 


1 


ord(5> 


! 






i 



IRI - symbol table ordinal of input routine for formatted direct 
access input initial call. 

UNIT code = numeric code for UNIT= specifier. 



IOCTL 


; 


L 


ine 


No. ! 





; 




IRI 


i 






FMT Code 






j 


.20 


i 













| 



FMT code = numeric code for FMT= specifier. 

.20 = symbol table ordinal of entry for label 20, 



IOCTL 



Line No. 







IRI 
Base of N 



REC Code 




REC code = numeric code for REC= specifier. 
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D8 



IOCTL ! Line No. ! O ! 



IRI 



.10 



END Code 




END code = numeric code for END= specifier. 



I I ii J i <u 



S 1 71 @ IVld% 

•— Aits t ^w a 



< IUVIC 



! Base of I ! 
+ _. + . 

i 

n « 



•+-+-■ 

!S! 

!C! 
i t 



■+-+• 



Mode is integer for I, the length is one. 



Mode of D is double precision 



-+ + 

I 

D 



! IODTA 






L 


ine 


No. 


1 


Mode 


t 








i 


! Base of 


D 























i 


! 




1 
i 








1 






! 


!S! 
!C! 


! I ! 
! ! 


i 
i 






i 














t 


i | 


! D ! 


i 



+ 

+ 



I OF 




L 


ine 


No. 


t 





1 






IRI 

















1 




IRR 

















1 





Call the input routine to issue part of the I/O list, 
call generated due to interaction of I and Ad). 
IRI = symbol table ordinal of routine to call. 
IRR * symbol table ordinal of input restart routine. 



Restart 
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SUBSC 



Line No 



+ +■ 

! Base of A ! 



! Base of I ! 

+ + . 




I p ip i 

!A!F! 
•PIP! 



D9 



SUBSC = subscript turple 
Mode is real for A 



IODTA 



PTR 







Line No 



•+ 

! Mode 



•+-+—+-+■ 
!I! 
!N! 

1 "J" ! 



+ - + ■ 

!A! 
!R! 
!Y! 



• + - + -- + - + - + - + + • 
!S! 
!C! 
i i 



I 
O 
D 



+ + + _ + + ___ + _ 

PTR points to the previous turple in the IL. 

INT designates an intermediate, i.e. ordinal field is a pointer 
to a previous turple. 



IODTA 



Line No 



+ 

! Mode 



! Base of B ! 

i 

! 
i 

+ 



-1 



10 



■T-T" 

!S! 

!C! 
i i 



T T T 

I 

D 



+ - + ■ 



I/O List DO collapse transforms <B< J) , J=l , 10) into a transfer 
starting with B(l) and transferring 10 items. 



+ + r— + + + 

! I OF ! Line No. ! ! ! 

+ + + + + + 

! IRR ! ! ! 

+ + + + 

! ! ! ! 

+ + + + 

Issue last restart call 
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D10 

The general form of an external function reference (CALL or 
function) turple is: 

+ + + + + 

! EXTF ! Line No. ! Mode ! ! 

! Base of Func . ! ! ! 

! ! Nargs ! ! 

+ + + 

Ufliifi is the mode of the function result. 

BaSfi-flf-Eunt* is the symbol table ordinal of the function or 

subroutine name to be called. 

bJacas is the number of arguments it was referenced with. 



6£±ual_Eanam£±an_16El_Iur_Els 

This turple specifies an actual argument of a subsequent 
subroutine or function call. All AP turples will immediately 
precede the associated EXTF turple. The form is: 

+ + :- + + + 

! AP ! Line No. ! Mode ! ! 

! BASE ! BIAS ! ! 

+ + + + 

1 ; 1 

+ + + 

Where: BASE is the symbol table ordinal of the actual parameter 
and BIAS is the offset. 
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ABG_IunEle 



011 



This turple is identical to the AP turple except that it denotes 
actual arguments to intrinsic functions. 



In the following example, F is a function. A, Y, Z, R and I are 
variables? and B is an array with lower bound of one. 

CALL X(A, Y+Z, F(R), B<I>) 

•¥ + 




Compute Y+Z 



.+ + +< 

! Line No. ! Mode ! 



AP 



i Base of R ! 



Aplist turple for argument R to function F. 




Call to function F with one argument. 
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SUBSC 



■+ 

i 

! Line No 



Mode ! 



!P! 
!A! 
iPi 



012 



■+-+■ 



! Base of B ! 

+ +■ 

! Base of I ! 
+ +• 



■1 




Compute subscript for BCD. 



AP 



Line No. 



Mode 



Base of A ! 



O 







First argument of CALL. 



+ + + + 

! AP ! Line No. ! Mode ! 

I ! !T ! 

PTR ! ! !N! 

« ! !T ' 



■+- + ■ 



PTR points to the Y+Z turple. 
turple. 



This is the second argument 



AP 



I Line No. 



Mode 



■+-+■ 
!T! 
!N! 
!T! 



PTR 







■+-+■ 







PTR points to the EXTF turple of the call to F. This is the 
third argument. 
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+ + + 

! Line No. ! Mode ! 



D13 



■+-+• 
III 
!N! 
!T! 



■+-+■ 



■+-+ 

!A! 
!R! 
!Y! 

+-+ 



+ 

i 



PTR points to the B(I) turple. This is the fourth argument. 



SUBR 



Line No. ! Mode ! 



! Base of X ! 



Call to subroutine X with four arguments 



lQ±cin£i£L_Eun£±ian_IuL£ls£ 

Inline intrinsic functions will be generated by the front end as 
explicit turples to perform the required operations. 
Out-of-line intrinsic functions will generate ARG turples 
followed by an INTF, intrinsic function call turple. 

+ + + + + 

! INTF ! Line No. ! Mode ! ! 

+ + + +-— + + 

! Base of func i ■ • • 

+ + + + 

i n t hi- t 

+ + + + 

dfldfi is the mode of the function result. 

Basg-,fl£-£uQC is the symbol table ordinal of the internal 

function name (SIN., SQRT#, etc.) to be called. 

bl5i£aa is the number of arguments. 
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2.1.8 Namelist Group Table (T.NLST) 



074 



NG. 



A variable length table (depending on the number of members 
in the group ) . 



NMEM 
15 



GROP 
15 



MEM1 
15 



MEM2 
15 



GROP 



Number of members in the namelist group 

Symbol table ordinal of group name 

««* . «_ _ * _• t_ < ._ ._ » • « « • • . 

" ^ ■»»»» W » WW d» ^ Wl u * t |S .u w 1 1 1 v 1 1 lllCIill/CI 



Subsequent entries are as MEM1 , MEM2, 4 per word. 
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2-1-9 Actual Parameter List Table <T.APL) (T. IOA) 

Each AP list consists of one entry per item- 



IA. 



! TAG ! BIAS ! MODE ! ATTR 

18 24 6 7 



•+ + 

5 



OA. 



OA, 



TAG: T-P8 "form of *IH* = symbol table ordinal 
BIAS: Constant offset 
MODE: Mode (type) 

iuv<i vuiiuuj. x vein 

ST: FWA stored to this item 

CHAR: Get (BCP, CLEN, BIAS) from T.CAC 

CRH: Character relational header 

ASG: Assigned format specifier 

FP: Formal parameter 

VAR: Variable do trip indicator 

The T.IOA entries are reformatted as follows: 

Noncharacter/FP 



! ATTR ! 

+ + 

6 

Character 

+ + 

ATTR ! 



TYP 
6 



LEN 
18 



ADDR 
30 



TYP 



LEN 



!/!B! 
i/!C! 
!/!P! 

A _ _!_ _ X 



ADR 



18 



*T T* 

2 4 



24 



FP 



+ + + . 

OA. ! ATTR ! TYP ! 

+ + + ■ 

6 & 



LEN 



SUBS 



18 



21 



ARG 
9 



ATTR: LCM: In ECS/LCM 

FP: Formal parameter 

IND: Indirect 

LST: Control information specifier 

VAR: Variable do trip indicator 
TYP: Mode or unit control code 
LEN: Number of elements 
ADDR: FWA 

BLP: Beginning character position 
ADR: FWA 

SUBS: Offset to formal parameters 
ARG: Formal parameter index 
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2.1.10 Cross Reference Table (T.REF) 



016 



One entry per symbol reference. Gathered (as requested) 
during front end processing and processing during rear end 
listing production. 

+ + - + + + 

! !M! ! ! 

! ORD !E! //////////// ! LINE ! USE 

! !Di i ! 

! !F! ! ! 

+ + _ + . + _ + 

IS 1 13 - 22 S 

URDz Symbol table ordinal 

HEDF: Map entry point definition 

LIl^E: Line number of reference 

USE: Usage symbol 
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2.1.11 Entry Point Table (T.ENT) 

One entry for each entry point in a program unit. 



El 



+ + + 

! NAME ! ORD ' 
+ _ + + 

42 IS 

NAME; Entry point name (DPCy left justified? zero 

filled) 
ORD: Symbol table ordinal 
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2.1.12 Entry Point Parameter List Table (T.ENTP) 



E2 



Each unique parameter list in a program unit has a T.ENTP 
entry. An entry consists of a header (EH.) and as many EP. 
words as necessary. A list is terminated by one (or more) 
zero bytes. 

+ + + + + 

i 



EH. ! FPC ! SUB I ! SBOI ! BIAS 

+ + + + 

12 15 15 IS 



SUB I: Subindex table bias 

SBOI: Level subindex table bias 

BIAS: CPL. bias of this list 

+ + + + + 

EP. ! ORD1 ! 0RD2 ! 0RD3 ! QRD4 ! 
+ + + + + 

ORDni Symbol table ordinal of the nth FP 
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2.1.13 Sub Block Table (T.SUB) 

+ 

POS ! FPNO 



SB. ! 
i 

+■ 



12 



+ +- 

! / ! 

! / ! 
! ! / ! 

+ + -.—+. 

9 3 



BIAS 



IS 



ORD 



IS 



E3 



— + 

i 
i 
l 

■ + 



POS: Instruction parcel shift count 
FPNO: Formal parameter number 
BIAS: Bias added 

Address o*f instruction to address substitute 



A-2-39 



S. 1.14 SubO Block Table (T.SUBO) 



E4 



+ +-~ -+ + + + 

SZ. ! POS !///! SLI ! /////////// ! ORG ! 

+ + + + + + 

12 3 15 

POS: 2036B + instruction parcel shift count 

SLI: SCM/LCM store instruction 

(3RD; Address of instruction to address substitute 
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2.1-15 Sub Block Index Table (T.SBI) 



E5 



+ + + 

IS. I FPN ! AD • 

+ + + 

12 48 

FPN: Formal parameter number 
AD: Address of Sub, this FP 
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E6 

2.1-16 Local Block Table (fixed table) 

+ + + + + 

LB. ! PARC i ///////////// I BLEN i ORG ! 
+ + + + + 

6 IS IS IS 

PARC: Parcel count 

BLEN: Length of block 

ORG: Program relative address/org counter 
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2.1.17 Data Statement Table (T.DATS) 



E7 



The entries consist of a one- or two-word header and as many 
constant entries as necessary. 



DA. 



C!R 

HIP 
i 



1— +-f 
1 1 



RP: 
ord: 

BIAS! 



+ . + . 

DB. !//////! 
+ + • 



ORD 



16 



8- " ^ ^ mm «% j*+ Jto sm. mm. Jt »m —■. — JL. 



BIAS 
24 



i 
i 



■-+ 



WC 



IS 



Replication needed (DB. word present) 

Symbol table format of FWA 

Bias off FWA 

Count (words or characters) not including DB. 



INC 



.+ +. 



CNT 



6 24 

INC: Increment 

CNT: Number of copies 



- + 



24 
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2.2.1 Token Buffer (TB.) 



E8 



The token buffer is the output of LEX (lexical analysis). 
LEX entokens an entire statement (or CS directive) into 
T.TB. T.TB is always at a fixed location and its FWA 
doesn't move as long as the token buffer is active. Token 
formats are as follows: 

Normal Tokens 

+ . + + 

• TOC ! TOT ! 

t— ■ ■ + .$. 

42 IS 

TOC: Token character string (variable and constant) 
TOT: Token type (value) 

LEX Formed Constant Tokens (Hollerith, Character, Octal) 



•+ +■ 

! LCON ! 
.+ + . 

9 



SHC 
IS 



CLCN 
15 



TOT 
IS 



SHC: Pointer to constant in constant table 

CLCN: Length of constant (Hollerith and character) 

LCON: Number of words in constant (Hollerith and 

character ) 
TOT: Token type (value) 

Statement Function Dummy Argument (made by STMTF) 



ORD 



DAC 



ACTE 
IS 



TOT 
18 



12 



12 



ORD: symbol table ordinal of dummy argument 

DAC: Dummy argument reference chain pointer 

ACTE: Actual parameter address (reference time) 

TOT: Token type = O.STFA 

Parentheses Tokens: These tokens originally are output by 

LEX and may be modified by the implied 
do list processing. 
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Left Parenthesis (LEX) 



E9 



+ + + 

i ! / : 

! S ! / ! 
! ! / ! 
+ + + 

3 3 

s: 



IOCP 



LLB 



TOT 



IS IS IS 



Switches 



col: 
eql: 



iocp: 

llb: 

tot: 



Paren level contains a colon 
Paren level contains an 
equal sign 
wo> wrray substring 
Pointer to matching right paren 
Pointer to next outer left paren (or null) 
Token type (value = O.LP) 



Right Parentheses (LEX): Normal token format 
Left Parenthesis (DO begin) (10) 




IOCP: Pointer to matching right paren 
IOIX: Pointer to implied loop index 
TOT: Token type ( value=0„DOBI ) 

Right Parenthesis (Do conclusion) ( 10) 



iuar 



iui 



24 



IS 



iosp: 

tot: 



Implied loop and marker (for parser) 
Token type ( value=O.DOCI ) 



Left Parenthesis (Do collapse begin) (10) 



+ +• 

! //// ! 

+ +• 

S 



IS 



IBCP 
IS 



IBCC 
IS 



TOT 
18 



IBCP: Pointer to closing right paren 
IBCC: Pointer to collapse conclusion token 
TOT: Token type ( value=O.DCBI ) 
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Do Collapse Conclusion (10) 



E10 



+ +■ 

! //// ! 
+ +■ 



ICIX 



ICCP 



TOT 



ICIX: Symbol table ordinal of Do index 
ICCP: Pointer to closing right paren 
TOT: Token type ( value=O.DCCI ) 
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2.2.2 Common Item Table (T.COMM) ^ 

The common item table contains one (one word) entry for each 
variable that appears in a common declaration. 

+ + + + + 

CT. ! ORD ! //// ! LNK ! RA ! 

+ + + + + 

IS 6 12 24 

ORD: Symbol table ordinal of variable 
LNK: Link to next member in same block 

wit ~ »*n i an no. st n r% r» « *e *e i.j< vh •» n *isn »» i .#•» *• i* 

> >n » >*S*«i *.*.▼€ aUui caa nj. «,iiiii <.uc is X UU r% 
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5. 2-3 Block Structure Table (T.BLST) 



E12 



The block structure table contains a variable length entry 
for each active program structure <Do loop or block IF) 
while the structure is still active- The block structure 
table entry format is as below: 



For DQ loop 



For block IF 



DOSI.W 






! DOII.W 

+ 

i 

+- 
i 



DOCI.W 
DORT.W 



+ 



! DO.W 

+ ■ 

! DOTC.W 

+• 

! DP.W 

+■ 

LA. (label) 
entries 
(variable no- ) 



+ 



+ 



+ 



+ 

LC.W 



4. + 

! BLIB.W 

+ + 

! SLlA.W 

+ 

1 



unused 



1 
1 

+ 

! LA. (label) 
! entries 

! (variable no. ) 

+ 

! LC.W 

+ 



For individual cells? the following formats apply 






r _ _. — _ — .l. \ 

■rorfflax i 



DOLI.W: Do loop limit value (TP. format) 

DOII.W: Do loop increment value (TP. format) 

DOCI.W: Do loop control index (TP. format) 

DORT.W: Inverted label of loop top (TP. format) 

DO.W: Do loop terminating label 



+ ■ 
DO. ! 
+ ■ 



FLG 



IS 



.+ + . 

! //// ! 
■+ + ■ 

6 



ORD 



18 



IQD 



18 



FLG: Do begin turple ordinal (T.PAR) 

ORD: Symbol table ordinal of terminal label 

IQD: Nonzero if implied do 
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DP, 



DOTC.W: Compiler generated trip count variable 

(TP. format) 
DP-W: Do loop information 



DQXL 



•+ +• 

! //// i 

-+ +■ 

c 



DDT I 



1« 






TURC 



1R 



— — + 



doxl: 
doti: 
turc: 



BLIB-W: 

blia.w: 
la.w: 



Generated ordinal of do exit (if zero trip) 
Symbol table ordinal of trip count variable 
Do conclusion skeleton ordinal 

Invented label of block bottom (TP. format) 
Invented label of next false branch (TP- format) 

Structure label encountered 



ORD 



+ + +- 

LA. ! ATT ! /////////////////////////////////////// ! 

+ + + 

4 38 18 



ATT: Attributes 

DEF: Label defined in structure 
REF: Label referenced in structure 
EXT: Label is exit from a do loop 
ENT: Label is entry in do loop 

ORD: Symbol table ordinal of label 

LC.W: Structure count word 




GLM: Generated bottom label must materialize 

DO: Symbol table index of header label (Do loop) 

LINE: Block origin source line 

CNT: Number of words in this block structure entry 
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2.2.4 Data Constant Table (T.DATI) 

Built when process DATA constant list. There are two forms 
of entry: 

Data Constant 



E14 




REP: Replication (=0) 

MODE: Constant mode 

PNT: Pointer to constant 

DLEN: Length (words or characters) 

Replication Header 



DI 




REP: Replication (=1) 

RL: Repetition list length 

RC: Replication count 
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2.5-5 Input List Item Table (T. ILI) 

The information in this table is gathered to decide upon 
issuing restart I/O calls on subscripted variables. 



E15 



+-+-+ 

!C!Ai 

//////////// !H!R! 
!A!Y! 
!R! ! 

+-+-+ 

IS 11 



ORD 



BIAS 



16 



24 



ORD: Symbol table ordinal 

BIAS: Bias (constant offset) 

CHAR: Operand is type character 

ARY: Operand is indexed array or substring 
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2.2.6 Equivalence Class Table (T.ECT) 

Class Member 

+ + + + 

EC. ! SYM ! BIAS ! SIZE ? 

+ + + + 

CJVM" Cumknl +nk1o nnWinal 

Ulna w/iuuuj- lsiwak wi v**iiau. 

BIAS: Offset of member from class base 
SIZE: Length of member 

Header 

+ + . + + 

EC. ! ! SPAN ! NM ! 

+ + _ + 4- 

12 24 24 

FIRST 12 bits zero 

SPAN: Length of class 

NM: Number of members in class 
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2. E. 7 Equivalence Name Table <T.EGUS> 

Nan character 

_ + 

_ + 



+■ 

EQ. ! 



LINK 



SUBS 



LINK: Index of member 

SUBS: Subscript of this item 



EQ. 




LINK: As above 

STF: Substring first 

SUB: Item subscripted 

SYMI: WB.W index of member 
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5-5.8 Keyword Table (fixed table) 

Used by front end processor FEC/LEX, 



+ 

KW- ! 

+ 



JMP 



ATTR 



+ +• 

I p£Q i 
+ + ■ 



LEN 



KEY 



10 



-JMPS Address of -the relevant statement processor 

ATTR: Attributes (see below) 

FEC: Context legality of statement (position) 

LEN: Length of keyword 

KEY: Address of keyword literal string 

KW.ATTR 

DON: May not be Do terminal statement 

NIF: May not be object of logical if 

LBL: Statement may have referencable label 

GEN: Statement generates turples 

BKD: Statement is legal in Block Data 

PWS: Statement is to be processed in skip mode 

IL: Statement has implied label 

NBS: Generates turples but no BOS is output 
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5«5«9 Statement Function Header <T,STF) 



F3 



+ + + + + 

! /// ! PEAR ! DACP ! TDK ! 
+ + + + + 

6 IS 18 IS 

PEAR: Previous EBTACK base for actual arguments 
DACP: Dummy argument reference chain head 
TDK: Duirany token (for PAR) 
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S.H.iO Intrinsic Function Table (fixed table) 

One entry per intrinsic function (both inline and external) 



H 



IT. 



DPC 



36 



+ - + 

!A! 
ATTR !R! JPAD 

!G! 

!C! 

+- + 

7 3 8 



! A 


M ! 


! R 


! 


! G 


D ! 


! M 


E ! 



•+ — + — + 

3 3 



ATTR: 

argc: 
JPAD: 
argm: 
mode: 

IT. ATTR 

char: 

byn: 

genf: 

xter: 

ansi: 

par: 



xnxrinsic name (DPC? left justified f zero filled) 

Attributes (see below) 

Required number of arguments 

Location of function description 

Mode of arguments 

Mode of result 



Character function 

Always call by name 

Generic name 

External intrinsic 

Defined by ANSI 

Parser has special processing 
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2-3.1 Program Unit Mode (MOD) 



F5 



The cell MOD is used by the front end processor to determine 
legality of syntax and semantics. 



MO, 



+ + 

////////// 



12 

clif: 
ptyp: 



blk: 
typ: 
mode: 



CLIF 



19 



+ - + « + . + ^ + _ + 

! P ! B ! T ! / ! M ! 

/////////////// !T»L!Y!/!0! 

! Y ! K ! P ! / ! D ! 

IP ! ! ! IEI 
+ -. + - + . + _ + . + 

17 3 114 3 



Same as WC.CLIF character information 

Program unit type 

FUN: Function 

SUB: Subroutine 

PRO: Program 

Block Data 

Explicitly typed function 

Mode (function only) 
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£.3.2 Parse Control Cells (ARGMODEr ARGCOMA* ARGMISC) 



F6 



These cells control end of expression transition in the 
parser . 

ARGMQDE 



AM, 



REF 

12 

dct> 

atr: 



ATR 
12 



COM 



PAD 



18 IS 



. J" US'!!* 



com: 
pad: 



Attributes 

ARE: Allow unsubscr ipted array name 

LEV3: Allow level 3 name 

COL: Allow colon 

EG: Allow » 

RP: Special right parenthesis processing 

EOS: Allow end of statement to unstack LP 

FUN: Allow function reference without list 

Address of routine to process comma delimited 

end of expression 

Address of routine to process right parenthesis 

delimited end of expression 



ARGCOMA 

Array Subscript Processing 
+ + 

• i 

SYM 



*-+ 

!V! / 

AC. !S! / 

!U! / 

!B! / 
+ _+ 

1 5 



DIMI 




IS 



IS 



IS 



VSUB: 
SYM: 
DIMI: 
cnt: 



Subscript constant flag 
Symbol table ordinal of array 
Dimension table index 
Subscript expression count 



Call or Function Argument List 



+ + . 

AC. ! ////////////////////// ! 
+ + . 

24 



MODE 



CNT 



IS 



18 



MODE: Mode (function only) 
CNT: Arguments processed (-1) 
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Intrinsic Function Argument List 




BOOL: Indicates Boolean argument occurred 
MAXM: Maximum argument mode 



CNT: Arguments processed (-1) 
Statement Function Arguments 



+ +. 

AC. ! ////////////////////// ' 



EARG 



CNT 



24 



18 



IS 



EARG: Address of actual argument (on EBTACK) 
CNT: Count of arguments processed 

Statement Function Body 

+ + 

AC. ! ///////////////////////////////////////// ! TBR 
+ + 

42 IS 

TBR: B4 restore address 

Do Loop Indices 

+ + 

AC. ! ///////////////////////////////////////// ! CNT 



42 
CNT: Do parameter count 
Character Substring 



IS 



+ +. 

AC. ! //////////////// ! 



MODE 



. + + 

! ///////////////// ! 



24 IS 

MODE: Mode of variable 



IB 
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ARGMISC 

Basic Intrinsic Function 

+ + + + 

AS. ' SYM ! //// ! ORD ! 

+ + + + 

Jfc> t> xo 

r*\/lu« ■ T-,4-^J^>-J>- ^nni-^^nn *-> -%*n£i / HDr 1 ii £ 4' 4IIC + 4 f 4 O/l 

DTI'ii iiiii'iioiu i unw i^uii iiomc •» ksi -wj *^i «. j>»-u»i »>.vj 

zero filled) 
ORD: Symbol table ordinal 

Array Subscripts 

+ + + 

AS, ! NAME ! //////////// ! 

+ + + 

45 18 

NAME; Array name (DPC, left justified, zero filled) 
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ft 






+• 



! COMCDXB ! UTILITY, IDP ! DPC to binary conversion ! External ! 
! ! ! routine DXB ! ! 


! COMCIDP ! IDP ! Interactive Debug Package ! External ! 


! COMCLFM ! IDP ! Local -file manager ! External ! 
! CQMCMCS ! IDP ! Collate routine MCS ! Internal ! 


! COMCMNS ! UTILITY ! Move nonover lapping bit ! External ! 
! ! ! string - fflMS ! ! 

! CQMCMVE ! UTILITY ! Move routine MVE • External ? 


! COMCPAC ! INITOO ! Control statement processor 1 Internal ! 


! COMCRDC ! UTILITY, IDP ! CIO coded input routine ! External ! 


! COMCRDW ! UTILITY, IDP ! CIO buffered input routines ! External ! 


! COMCRSR ! IDP ! Register restore routine ! External ! 


! COMCSBM ! UTILITY, IDP ! Set block of memory to ! Internal ! 
5 ! ! supplied value ! ! 


! COMCSFN i UTILITY, IDP ! Space fill name routine ! External ! 


COMCSST ! UTILITY ! Shell sort routine ! External ! 


! COMCSTF ! INITOO ! Set terminal file routine ! External ! 


i CQMCSVR ! IDP ! Register save routine ! External ! 


! COMCSYS ! IDP ! Process system request ! External ! 
j i ■ 


! COMCTOK ! IDP, LEX ! Token generation routines ! External ! 


! COMCWOD ! UTILITY, IDP ! Octal DPC conversion ! External ! 


! COMCWTC ! IDP ! CIO coded output routine ! External ! 


! COMCWTH ! UTILITY ! CIO Hollerith output ! External ! 
! ! ! routine ! ! 


! COMCWTO ! UTILITY ! CIO write one word ! External ! 


! COMCWTW ! UTILITY, IDP ! CIO buffered output ! External ! 
! ! ! routines ! ! 



A-3-a 



3.0 OTjDECKS 

FTN5 uses several comdecks. The purpose of comdecks is: 

Standardize functions across the common product line and 
within a product (FTN5). 

n -. j. . j-„ «,tj n <t-nn!,inru f r»r-» 1 v £ * v rime r» 1 a r a ^ _ 

• RCUULC IllflllllCiiaiiuc ^w«i*/ i * « w.w r - — - 

FTN5 uses two classes of comdecks: 

Internal: Qn FTN5PL, maintained by the project 

External: On a secondary PL, maintained by owner of 
secondary PL- 





! COMDECK ! CALLING DECK(S) ! CONTENTS ! STATUS ! 


! CCOMRPV ! UTILITY ! Reprieve routines RPV, FRA ! Internal ! 


! COMACPU ! FTNSTXT ! General CPU macros ! Internal ! 


! CQMADEF ! FTNSTXT ! Structured field definition ! Internal ! 
« « ! macros ! ' 


! COMAERR ! FERRS, RERRS ! ERROR macro ! Internal ! 


! COMAIDP ! FTNSTXT ! Debug package macros ! External ! 


! COMAMGM ! FTN5TXT ! General macros ! Internal ! 


i COMAGCG ! QCGC, FUN, REG, GEN ! QCG macros ! Internal ! 


! COMATOK ! IDP, LEX ! Token generation macros ! External ! 
! COMCBUB ! IDP, LEX ! Burst routine BUB ! External ! 


i COMCBUN ! IDP, LEX ! Burst routine BUN ! External ! 


! COMCCDD ! UTILITY, IDP ! DPL conversion routine CDD ! External ! 


! COMCCFD ! PUC ! Floating DPC conversion ! External ! 
1 { ! routine CFD ! • 


! COMCCIO ! UTILITY, IDP ! CIO I/O routines ! External ! 


! COMCCQD ! FTN, IDP ! Octal to DPC conversion ! External ! 
i i ! routine COD ! l - 
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F10 



! CQMCXJR i IDP 



XJR restore code 



■+ + 

! External ! 



, CQricZTB , UTILITY, IDP 



Zero to blank conversion 



! External i 



! COMDDMT ! CSNAP, FSNAP , BSNAP 
! COMDTOK ! FSNAP 



Table dump routines 



+ + 

! Internal ! 



Token buffer dump format 



External 



! CQMFCIP ! FTN, INITOO f INIT20, 
! ! OVLIO, 0VL2O 



Compiler installation 
parameters 



! Internal ! 
i t 



! CLFFDST » DECL 



S Double word table sort 



! Internal ! 



! COI*FECB ! PUC 

! i 



Evaluate constant bias and 
substring 



! Internal I 
t i 



! CQMFFEI ! INITOOf INITIO, INIT21 



Front end initialization 



Internal 



COMFERR ! FERRS, RERRS 



Common error texts 



! Internal ! 



COMFGFD ! GEN, GRIDGE 



Generate file definitions 



! Internal ! 



! COMFGOI \ INITOO, INITIO 
i i 



Global overlay 
initialization 



! Internal ! 
i i 



COMFICP ! GEN, BRIDGE 



Issue CP and GPL tables 



! Internal ! 



COMFISA ! GEN, CCGC 



Issue save AO on RJ 



! Internal 



! COMFITS ! QCGC, CCGC 



Issue temporary storage 



! Internal ! 



! COMFMAV ! GEN, CCGC 



Mark vardim appropriate 



! Internal 



CCWOSC ! GEN, CCGC 



Output addsub code 



Internal 



! COfFPLI ! GEN, BRIDGE 



Print limit generator 



! Internal ! 



COMFROR ! INITOO, INITIO, 
! INITS1, INIT22 



Reset rounded operations 



! Internal ! 
i i 



! COMFSCB ! FUN, BRIDGE 



Subsume constant char bias ! Internal ! 



COMFSCS ! FEC, RLIM< 



Scan table with supplied 
mask 



! Internal ! 
i i 



■+ + 

! Internal ! 
i i 



! COMFSID ! BRIDGE 
i i 

+ + 



Select integer divide 
skeleton 
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F11 



+ + 

i CGfFSIM ! BRIDGE 
t i 



Select integer multiply 
skeleton 



.+ + 

! Internal ! 



COMFSKL ! QSKEL, FSKEL 



Front end skeleton formater ! Internal ! 



CQMFSMQ ! BRIDGE 



Select mode subskeleton 



! Internal ! 



COMFSMK ! BRIDGE 



Select mask subskeleton 



! Internal 



COMFSSH ! BRIDGE 



Select shift subskeleton 



Internal ! 



! COM.- i i L ! *- i N 



itie line template 



: internal : 



! COMFUSE ! QCGC, FAS, CCGC 
! COFFWIN ! QCGC, CCGC 



Process use pseudo 

Write instructions to 
prebinary 



! Internal ! 
.+ .$. 

! Internal ! 
i i 



! COMPCOM ! FTN 



COMPASS inter-Face area 



External ! 



i COMGSVR ! PEM, I DP 



Save and restore registers 



External 



i CQMSEIS 



QSKEL, FSKEL, INITOO, 
INITIO, INIT21, 
CONRED, GEN and 
imbedded in COMFSKL 



Skeleton description 
definitions 



Internal ! 



+ + 

Error skeleton definitions ! Internal ! 



COMSERR ! PEM, FERRS, RERRS 



! COMSIDP ! IDP, FSNAP, CSNAP, 
! ! RSNAP 



IDP interface text 



! External ! 
i i 



•+ + 

! Internal ! 



! COMSIOC ! FT1SETXT, 10, FAS 



I/O control codes 



i rnMCi bt i pi ir _ ocr _ i tot 

ww» tw i _ i ,» i i ww f l \b_w J L_.LW I 



uutai u-xuun urx^iii (.auie 



COMSPBD ! FTN5TXT 



Prebinary definitions 



Internal ! 



COMSPSU 



QCGC, CCGC, FAS, 
FTN5TXT and imbedded 
in COMFWIN 



Pseudo instruction 
definitions 



Internal ! 



■+ + 

! Internal ! 
i i 



! COMSQCG ! QCGC, FUN, REC, GEN, 
! ! FSNAP 



QCG macros 



.+ + 

! Internal ! 
i i 



COMSQRF ! QSKEL, FSKEL, QCGC, 
! FUN, REG, GEN and 
! imbedded in COMFSKL 



QCG register associates 
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COMSSYM ! FTN5TXT, SYMDEFS 



Symbol table definitions ! 

also definitions for vari- ! 

able dimension information, ! 

formal parameter , common ! 

block tables. ! 



Internal 



COMSSYC 



FERRS 



\ Symbolic representations of ! Internal ! 
! symbol table class bits ! ! 



CQMSTAB ! PUC, CCGLIM<, CCGC, 
! INIT22 



Shared tables 



! Internal ! 
i t 



COMSTAD ! PUC, CCGLIl*8<, CCGC, 

! INIT22 and imbedded 

! in CGHCDTD and 

! COMSTAB 



Shared tables (variable) 



•t T 

! Internal ! 
; i 

; ; 

i i 



+ + 

! Internal ! 
; i 

; i 

i i 



COMSTAS ! PUC, CCGLIIW, CCGC, 

! INIT2H and imbedded 

! in CGHCSTD and 

! COMSTAB 



Shared tables (static) 



! COMSTQK ! IDP, FSNAP, LEX 

+ + 

DEFINS ! QSKEL, FSKEL, FUN, 
! REG, GEN and im- 
! bedded in COPFSKL 



! Token generator interface ! External ! 
+ + + 

! Machine opcode definitions ! Internal ! 



FSCALE 



CQNRED 



! Constant conversion 
! routines 



! Internal ! 
i i 



! FA=CLO ! UTILITY 

+ + 

! FA=DEFS ! FTO5TXT 



! RM close routine 
. + 

! RM I/O macros and 
i 



! External ! 

>+ + 

! External ! 



! FA=EOF ! UTILITY 
+ + 

! FA=EOR ! UTILITY 



! RM end of file routine 
+ 

! RM end of record routine 



! External ! 

.+ + 

! External ! 



! FA=FLSH ! UTILITY 
+ + 

\ FA=OPE ! UTILITY 



! RM flush holding buffer 
. + 

! RM open routine 



! External ! 
+ + 

! External ! 



! FA=REX ! UTILITY 
+ + __« 

! FA=RDW ! UTILITY 



! RM coded input routine ! External ! 
>+ + + 

! RM buffered input routine ! External ! 



! FA=RWX ! UTILITY 
+ + 



! RM rewind routine 

.+ 



! External ! 
■+ + 
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•+ + 

! External 
i 



! FA=SET 
i 

! FA=WTH 

+ 

! FA=WTW 



UTILITY 



UTILITY 
UTILITY 



RM file initialization 
routines 



RM coded output routine ! External 
RM buffered output routine ! External 



OPRDEFS 



RLINM, CSKEL 



CCG intermediate language ! External 

Ho-C-i ni +i nn«; ! 



+ 

! OPTIONS 



FTN5TXT 



Installation parameters 



! Internal 



PARSKEL 



Imbedded in COMFSKL, 
thus in QSKEL, FSKEL 



Parser skeleton tables 



Internal 



■+■ 



SKEL 



QSKEL, FSKEL, CSKEL, 
imbedded in COMFSKL 



Instruction skeleton 
expansions 



! Internal 



! SKOP 



QSKEL, FSKEL, CONRED, 
GEN, BRIDGE, CSKEL 
imbedded in COMFSKL 



Skeleton field definitions 



Internal 



SKPCONQ 



QSKEL, FSKEL, CONRED, 
QCGC, imbedded in 
COMFSKL 



Field type constants 



Internal 



SKPSET 



QSKEL, FSKEL, CONRED, 
QCGC, imbedded in 
COMFSKL 



SKPSET macro 



Internal 
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B . ^CK-jSifcO«BQyiIliiE^DESCBIEIICttilS 



F14 



This section describes the decks which comprise FTNS, the 
routines which make up each deck, the interfaces and data 
structures involved and any special algorithms or 'tricks' 
employed. This document doesn't recite code? register usage? 
called routines, etc. For these implementation details, the 
reader is referred to the relevant listings. 

1. Texts 

-^ y% — _ j * _ __._»__•___. 

j^ s i . r* ^a n i sa rnu t t to jgcs 

3. Front end routines 

4. QCG routines 

5« Rear end routines 
6. CCG routines 

Outline for the individual decks is: 

1. Abstract - the function of the deck. 

5. Interfaces - what decks the deck interacts with. 

3. Data structures defined/utilized. 

4. Routine descriptions. 
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1-0 IEXIS ■ 

FThS uses system texts to provide macros* micros and assembly 
constants to the decks comprising the compiler. To be included 
in a system text? the macro? micro or constant should have 
general applicability. If a constant is used in only one deck, 
it should be included in that deck only. If a data structure is 
used only by a small number of decks (e.g., GCG only), use of a 
common deck should be considered. 

The system texts defined for FWB are: 



L_ I flk|K_. t'*T« 



i he general systems text. Used by front end* 
rear end, GCG and CCG interface decks. 



5. CMPLTXT: CCG interface text. Used by CCG interface 

routines. 

3. CCGTEXT: CCG text. Used by CCG decks. 
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1.1 FTfsSTXT: FORTRAN 5 Assembly/Installation Text 
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6kS±L££±: FTN5TXT consists of macros and micros used by FTN5 
to access data structures, construct data 
structures* provide system interface and provide 
product/routine interface: FTN5TXT also provides 
assembly constants pertaining to data structure 
definition, compile limits, etc. 



Id jjgr. fc fl£& » hiNbiXi is used to assemble 
and CCG interface decks. 



front end, rear end, QCG 



Provided by comdeck OPTIONS. The installation parameters 
which are user modifiable at installation time. 

b . G£n£Lal_6sasmkIx-.£flas.±ajQ±s. 

These constant values pertain to compiler limits (boundary 
values). The assembly constants provide symbolic 
representation of compiler and language constraints and are 
intended as a maintenance aid. If future requirements 
change, changing the relevant symbolic constant and 
reassembly of the relevant deck(s) should effect the change. 

c . BCLIZQ 

Provided by comdeck FA=DEFS. The constants and macros used 
for the CYBER Record Manager I/O interface. 

d . Ds±a-S±cu£±uc.£-.D£f ini±ian_Baj:iLas. 

Provided by comdeck COMADEF. The macros and micros used to 
provide symbolic representation of data structures. The 
macros are: 

DESCRIBE: Describes the beginning of the structure. Gives 
the prefix name and the length of the 
structure. Names the structure (optional). 



DEFINE: 



Field definition macro. Assigns a symbolic name 
to the bit position (within the DESCRIBEd 
structure), length (and a mask bit for some 
values). 



DEGU: 



Defines an equivalent structure to a previously 
defined field. 
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REDEF: 

BFLIT: 
BFMIC: 
BFHW: 



Resets the field painter for redefinition of a 
field. 

Creates a bit field mask literal. 
Creates a bit field micro- 
Creates a bit field mask word. 



G\ 



y£aua_aa£,£.fis 



Test mode only. Macros to provide snap and dump output. 



Interactive 



CORE: Snapshot of core. 

DUiPT: Table dump. 

STRING: Token buffer dump. 

PRINT: Print contents of core locations. 

USF=: Generate user flag parameter cell. 

Test mode only. Provided by comdeck COMAIDP 
debug package interface macros. 

BREAK: Place a breakpoint. 

FRK=: Generate frequency parameter list. 

REG: Register snapshot. 

RGR=: Generate register parameter list. 

SNAP: General snapshot interface. 

SNG=: Generate indirect address fields. 



Provided by comdeck COMACPU. Macros of a general nature, 

en i +aK1 <a inr nca Kw anu m m s-t v-it ■ v- 4- 

■»-—•«. ->.->«.»*»w • wi ■**£*** l* J 911/ f « WUU4. u . 

BITMIC: Generate a micro of bit fields. 

LETMIC: Generate a micro of bits? corresponding to an 

alphanumeric string. 

OPDEF to clear an X register. 



BXQ: 
IXI 

xj/xk: 

IXI 
XJ/XK, 

BN: 
move: 

SUBR: 



Integer division OPDEF. 



Integer division OPDEF. 

Move data block. 

Subroutine entry/exit definition 
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General Macros Comdeck COMAMGM, 



BSSENT: 
BSZENT: 

call: 
bc: 

conent: 
CW; 

equent: 

cn>i icrvr- 
HXQ: 

TOJ^' 

ldbit: 
ldx: 

LXQ: 

moveb: 
mxx+x: 
mxx-x: 

RMT=: 

rpvdef: 
rpvfwa: 
rpvon: 
rpvqff: 
sb it: 

setmem: 

wc: 

wxx: 



Generate an entry point and BSS. 

Generate an entry point and BBSZ. 

Issue RJ to external subroutine. 

OPOEF to convert character count to bit count. 

Generate an entry point and CON. 

OPDEF to convert character count to word count. 

Generate an entry point and EQU. 

vciici a wc id i * w*bw«;iii«a«ft» nnu fc_i-* u-r « 

OPDEF to shift a structure field to the high order 

bit position. 

Tcchd USE n seudOa 

Set one bit in a register. 

Load register with a value. 

Left shift redefine OPDEF. Eliminates zero shifts, 

Move bit string. 

OPDEF for maximum function. 

OPDEF for minimum function. 

Force micro evaluation for remotes. 

Entry definition for REPRIEVE. 

FWA definition for REPRIEVE. 

Turn on REPRIEVE. 

Turn off REPRIEVE. 

Shift a specified bit into the high order (sign) 

position. 

Set memory block to given value. 

OPDEF to convert word count to character count. 

OPDEF to convert character count to word count and 

remaining character count. 



i . Comp i 1 e r , Spe c i f i c_ Ma c ros 

Macros to provide function relevant only to FTN5. 

ACTTAB: Activate a table (managed). 

ADDREF: Add a reference to the cross reference table 

ADSYM: Add an entry to the symbol table. 

ADDWD: Add a word to a table. 

ALLOC: Allocate managed table space for a table. 

INATAB: Inactivate a table (managed). 

ANSI: Process ANSI diagnostic. 

CLAS= Load class bits into X register. 

EMIT: Emit a turple. 

FATAL: Process FATAL diagnostic. 

HEREIF: Define statement processor. 

LITKEY: Generate a keyword literal. 

LOVER: Load a FTN5 overlay. 
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pia: 

pline: 

plug: 

scan: 
sect: 
shrink: 

SUBKEY : 
SYMASK: 

TAfCCV • 

triv: 
trubl: 

lilADKO 

wcode: 
=xlib: 



Convert instruction for listing. 

Coded output interface. 

Modify compiler code during execution (test mode 

only ) . 

Search routines interface. 

Assembler group 1 instruction generation. 

Collapse managed table to given length. 

Define subkeyword. 

Generate symbolic mask. 

i«3 iiivenieu CAccruox. 

Process TRIVIAL diagnostic. 
Abort compilation (test mode) 
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i~ i ' «-* «- =r : 



ivxiim y lMuiiij^ LAV, s 



Write code to prebinary. 

Define external (library) routine name. 



3*mkfll_Qe£ioi±iaas 

Tables of symbolic values pertinent to compilation 

PASS=: Table manager phase information 

IOCAD: I/O control code values 

ODEF: Token value definitions 

CH.: Charmap define/describe. 

Micros: ODEF related micros 

DUC=: QCG EMIT constants 

PSUD: Pseudo instruction values 

IPSUD: Pseudo label instruction values. 

Iakl£_Qfi£iiii±iQ.ns 

DESCRIBE/DEFINE for data structures of FTN5. 
Prebinary table. Comdeck COMSPBD. 



PB. 

UiA 

wc. 

CB. 
FP. 
TB. 
DH. 
Dl. 
DE. 
DO. 
DP. 
LA. 
LC. 
EC: 
EG. 



Symbol table. Comdeck COMSSYM. 

Common block name table. Comdeck COMSSYM. 
Formal parameter table. Comdeck COMSSYM. 
Token buffer. 



Dimension table. 



Block structure table. 
Equivalence class table. 
Equivalence item table. 
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TH. , 

SP. , 

TP. : Turple descriptions (ID. 

AG.: Assign statement label table. 

HG.Z Name list table. 

IA. , 

OA. : Actual parameter list table. 

DA.; Data statement table. 

DI.: Data constant table. 

TT • Innn+ J + am 1 ie+ +akl B 

mi a. t 1 |-r vjl w a bcm a- a a *. vau j.ei 

XR. : Cross reference table. 

CR. : Cross reference attribute letters. 

l_l . a ;_ : : 1. J j *# w A I J 1. ibu Aba 

EH. , 

EF. : Entry parameter list table. 

SB. ? 

SR . <t 

IS., 

LB. : Block tables. 

F.PIK: Machine opcode description table. 

MO.: MOD cell description. 

PM=: Parser mode values. 

AM., 

AC, 

AS.: Parser interface cells (ARGMODE, ARGCOMA, ARGMISC) 

definitions. 

KW. : Keyword table. 

SF. : Statement function table. 

IT.: Intrinsic table. 

INTF-: Intrinsic table entry macro. 
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1.3 CMPLTXT: Compiler Products Assembly Text 

6k£±H££±: CMPLTXT consists of macros and micros used by the 
CCG interface decks. 

lQ±£H£a£.a: CMPLTXT is used to assemble the CCG interface decks. 

« • u£i.ik£tuJt 

See FTISSTXT (1.1). Comdeck OPTIONS. 

b . Qa±a-3±£.u£±un£_Qs£ iniiisiL-aacxas 

See FTN5TXT (1.1). Comdeck COMADEF. 

c G£n£L£l-£ojDEil£LJ3a£rjL& Comdeck CCOMGCM. 

1~XQ: Left shift redefine OPDEF. Eliminates zero 

shifts. 
RPVDEF: Entry definition for REPRIEVE. 
RPVFWA: FWA definition for REPRIEVE. 
LISTL: List one line. RM interface. 
NUPAGE: Page eject. RM interface. 

<J - Ina±nu£±iflia-.Dfiatc.i£±flii-Eifilila . Comdec k ccg ilfd . 

CCG describe/define for the IL. (At BRIDGE time) 
e- QE_£ad£«Q£££ni£±a££ (Comdeck OPRDEFS. 

CCG describe/define for the IL. (Return from CCG) 
*• ^ISI.Ina±LSl£±i!lQ_.DfiSL£rJL£±aiia Comdeck PSODEFS. 

Describe/define for CCG IL pseudo opcodes. 

NOTE: OPRDEFS and PSODEFS calls are imbedded in CCGILFD. 

9 - £Q£_lEl±£££ £££ J3££C.Q£ 

WRITEP: Write pseudo opcode to SLIST file. 
ADDWRD: Add a word to a managed table. 
ALLOC: Allocate managed table space. 
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1.3 CCGTEXT: Common Code Generator Assembly Text 

&kS±£ax±: CCGTEXT consists of macros f micros and assembly 
constants used by the CCG decks. 

Ili±£Hia££: CCGTEXT is used to assemble the CCG decks. 

Qa±a_5±iLU£±iir_ss 

See FTTVBTXT <i.l). Comdeck OPTIONS. 

See FTN5TXT (1.1). Comdeck COMADEF. 

c . BCULZD 

See FTN5TXT (1.1). Comdeck FA=DEFS. 

d . SgQe£.aI-.CfimEil£L«£3dcc.fls 

See CMPLTXT (1.5). Comdeck CCOMGCM. 

e. ££Q£LaJ.J3a^rJ2S (Less so than CCOMGCM) 

LEN: Count number of names in micro list. 

MXX+X: OPDEF for maximum function. 

MXX-X: OPDEF for minimum function. 

BIT: Set symbol to power of 2. 

CALL: Issue RJ to external subroutine. 

ENTRY.: Define entry point and contents. 

EGENT: Generate an entry point and EQU. 

MOVE: Move a block of data. 

PLUG I Mfn#"H£vr nmn i lar *-n/4« /4(ininn ava<-n-4-*jnm 

NAtE: Define local subroutine entry point. 
SETCORE: Set block of memory to a given value. 
SETZERO: Set block of memory to zero. 

f- C£G_Q£klifl_!3acjias Comdeck CCGDBGM. 

PRINT: Print the contents of a list of locations. 

TRACER: Define routines/phases to trace. 

TRACE: Conditionally snap table contents. 

SNAPRL: Interpretive dump of IL. 

DCALL: Call debugging routine. 

REGSNAP: Snap registers at entry points. 

SNAPT: Snap table using pointers. 



G6 
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Inisc.aciiidfi-.DfikuaJ3ac.Lfls Comdeck dbg=mac. 

BREAK: Place a breakpoint. 

FRK=: Generate frequency parameter list- 

REG: Register snapshot. 

RGR-: Generate register parameter list. 

SMAP: General snapshot interface. 

SNG=: Generate indirect address fields. 

USF=: Generate user flag parameter cell. 

Instruction Descriptor Fields 
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InifiLiDfidiaifi-.Lanauaafi-.DfiaflE.i£iflJia 

BI.: BIT table 

!*ft-.: MOD list 

T.: Temporary equivalence table 

LC.: Label change table. 

yfiSi-£r_fl£££S.fl£._ luifiExaflfi 

A series of EQU's defining external cells in the host 
processor (FTN5). 

Qomd&L\L-.QQmsm 



Symbol and other table descriptions 
(1.1). 



Described in FTN5TXT 



QQS-.Uaflr.fls 



ccg.sst: 
setbi: 

AnnLdRQ • 
ALLOC: 

process: 

EXT=: 

tables: 



Generate SST call. 
Set Bl=l. 

Allocate managed table space. 
Define processor addresses. 
Declare names of externals. 
Declare names of dynamic tables. 
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2.0 £B^LE-£QUII&£3 

The decks grouped here are those that are common to the 
front end and r&ar end. Some are used by the CCG overlay, 
some not, but the multiple use in several overlays 
determined the location within the routine descriptions. 

Several decks perform similar functions, although utilized 
by only one overlay. They can be thought of as cradle 
functions and are grouped here for convenience. These 
include initialization routines, snap routines (including 
IDP, test mode only), and linkage routines. 

Usage of the routines/decks in question is described in 
the pertinent interface section. 
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2.1 



FTN: Global Cells and System Interface 
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6&S±L3£.±: FTN contains compiler installation parameters , 
intermixed COMPASS communication cells, file 
management tables? compiler global cells, 
control statement option cells? system 
interface subroutines* compiler overlay loader 
and termination routines. 



inxaciacas < 



h i N consists of static and dynamic 
information* some of which is bound at 
installation time (system defaults* 
installation defaults)* some a± control 
statement recognition time* and some by a 
combination (defaults for missing control 
statement parameters). Initialization is 
performed on a one-time basis by INITOO and 
the information survives all future overlay 
loading (including COMPASS). The system 
interface routines are environment dependent 
and are bound at installation time. FTN is 
present in all overlays. 

Qa±a.£±r_u£.±ur.£2 

Most of FTN's data structures are simply cells* which 
contain flags* file names* etc.* which were directed by 
the control statement (or defaulted). In sequential 
order* these arel 

a. QQSEQIE- The Comdeck which contains micros and equs 

for installation defaults. Provides default settings 

for control statement parameters and for CIO interface 
buffer lengths. 



rnivCACC T«4-« n £-.~. 






>ACt_ , . . 

micros* equs and entry declarations to provide other 
decks an interface to COt^COM's cells. This area 
contains cells of information used by both FTN5 and 
COMPASS (when intermixed). 



c EIl£_£laiiaa£lD£0±«Iab:le.s. . FET/FIT macro expansions for 
standard files utilized by FTN5. These include INPUT* 
OUTPUT, ERROR, LGO, Prebinary* Intermediate File and 
Cross Reference File. 

d. £oj2±Lfll_3±a±£ID£n±_EIaa£. Calls preset with 

information from COMFCIP and* dependent upon the 
control statement, reset and/or reformatted by INITOO, 

e- Ii±ls_Linfi_l£TD£la;fc££ - Used for source listing. 

Appears here because the title line information is 
needed for error output regardless of the requirement 
for source listing. 
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Routine Descriptions 

a. LDCOM. Forms loader request for loading COMPASS <1,0) 
overlay. 

*>■ LOVER. Forms loader requests for loading the compiler 
overlays. 



Determines which overlay is to be loaded, and from 

mio i auui wfci i i * j. w w j .» .« v . — < • 

registers and exits to LOV. 



— mo i. auui bb i i * j. w w » — — ^- . — . _^ • - »--.--. — r -. — .__, _- 



Cm LOV. Load overlay. Accepts information from LDCOM or 
LOVER and sets appropriate communication area 
cells/flags. Clears REPRIEVE and SPY requests as 
necessary and performs the overlay load request. 
After control is returned, SPY is cranked up as 
necessary, and control is transferred to the requested 
overlay. Loader failure results in an abort. 

d« SJOP. Return point from intermixed COMPASS. Performs 
some restoration and falls through to ... 

e. LQEEI- Load Primary overlay. This routine reloads 
the FTN5 overlay which COi^ASS displaced. Also used 
by INITOO to fetch the (1,0) overlay or (2,0) when 
0PT>0. 

*• MBffjERR. Outputs insufficient FL message. 

9- IDPCHK. Breakpoint check for each overlay loaded. 

Determines if break requested for the current overlay 
and, if so, transfers to IDP for processing. Test 
mode only. 

h- QNSPY. Interface to PPU program SPY. Turns SPY on, 
as necessary. 
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QFFSPY. Ditto, turns SPY off. Both routines 
conditional upon .SPY, ON. 

COD. Convert octal to DPC. Comdeck COMCCQD* 
Converts an octal constant of up to 10 digits into 
display code. Leading zeros are suppressed and both 
right- and left-justified results are available. 
Space filled. 
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2.2 UTILITY: Common Utility Routines 

&k£±£.a£±" UTILITY contains routines of a general ? 
service nature. 

lQ±££.£a£L£S : All routines in UTILITY are provided via the 
common comdecks and reside on a secondary PL. 
The deck provides entry names for the 
routines. Most entry names are '=' suffixed. 
Present in all overlays. 

Qala_£±E.u£±ur_£s. 

None of note. 

Rfiu±in&_QsscxiE±iGus 

a. £QQ Constant to decimal DPC conversion. Converts a 
binary constant (up to 10 digits) to space filled 
DPC. Left- and right- justified forms returned. 
Comdeck COMCCDD. 

b. DXB- DPC to binary conversion. Converts DPC 
representation of an octal or decimal constant to 
binary. Constant (DPC) may be 8 or 9 digits? 
depending on whether it is suffixed with base 
indication (B or D) . Comdeck COMCDXB. 

c E&53EI- Set file environment table for CID directed 
I/Of or record manager I/O (conditional assembly). 
The CIO flavor sets the buffer address in the FET. 
The RM version initializes holding buffer addresses in 
FIT and pseudo FET. Comdeck FA=SET. 

dm oy£- Move block of data. Given a source address ? 
word count and destination* a block of data is 
relocated. Move may be either direction? is performed 
word at a time and requires two styles of move in 
order to preserve the moved data. (Style dependent 
upon upward or downward move.) Comdeck COMCMVE. 

e. REy. Reprieve Processor. When the program (FTN5) is 
abnormally terminated? RPV takes control to issue 
dayfile messages concerning nature of error? location 
of error (and in test mode? the DECK (IDENT) in which 
the error occurred). Output mode files are finished 
and the error condition is reset to provide EXIT 
condition processing. Comdeck CCOMRPV, 

f. ERA- Find Relative Address. Used by RPV to compute 
relative address within an IDENT (DECK? ROUTINE) when 
a table of addresses is provided. Resides on comdeck 
CCOMRPV. 
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g« dfc!3- Move Nonaver lapping String. This routine will 
move an arbitrary bit string from one location to 
another in core. The source and destination locations 
may start at any location within a word and may cross 
word boundaries. Source area is unchanged? and the 
destination area may not overlap the source in any 
manner. Comdeck COMCMNS. 

h. 3B&- Set block of memory to a given value. The value 
is set into the first word of the block and the set 
continues word at time for the length of the block. 
Comdeck COMCSBM. 

i. SEfcj- Converts trailing '00' characters to 'BS' blank 
characters. Based on a Mansfield algorithm. Comdeck 
COMCSFN. 

j. 551- Shell Sort Table. Sorts a table of one-word 
entries into ascending order. Standard shell sort 
algorithm. Comdeck COMCSST. 

k. &QQ. Convert binary word to DPC. This routine 

converts binary (octal) data to DPC. Algorithm by 
C.R. Willis. 64-character set. Comdeck COMCWOD. 

1. 2IB- Converts all zeros (binary) to blanks. 
Algorithm from Mansfield. Comdeck COMCZTB. 

m. £IQ. I/O function processor. Provides the inter-face 
to system PP I/O processor routines. Comdeck COMCCIO. 

n- EDQ- Read coded line. Reads a zero byte terminated 
coded line from a buffer. Comdeck COMCRDC. 

o. BOW- Read words to working area. Transfers a given 
number of words from a CIO buffer to a user-def ined 
working area, Comdeck COMCRDW. 

P. BQX- Read exit. Exit routine from RDW to user. On 
comdeck COMCRDW. 

q - L£S- Load circular buffer. For RDW. On comdeck 
COMCRDW. 

r. yifcJ- Write coded (Hollerith) line. Transfers coded 
line from working storage to CIO buffer. Comdeck 
COMCWTH. 

s- yiQ. Write one word. Writes one word to a file 

(actually to a buffer, which is output as necessary). 
Comdeck COMCWTO. 



G13 
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t. WJW- Write from working buffer. Transfers data from 
a working buffer to a CIO buffer. Comdeck COMCWTW. 

u- WI£» Write exit. Exit routine from WTW to user. On 
comdeck COMCWTW. 

v. DCB. Dump Circular Buffer. For WTW. On comdeck 
COMCWTW. 

w. FA=CLO. Close a file if o n en. RM interfaces 
Comdeck FA=CLO. 

Xa p^=£np B Lj r i+ S end-of-file= RM interface^ Comdeck 
FA=EOF. 

X- E^ziQB- Write end-of-record. RM interface. Comdeck 
FA=EOR. 

2- FA=FLSH. Flush file holding buffer. RM interface. 
Comdeck FA=FLSH. 

aa. FAfOPE. Open a file. Prevents (dishonors) redundant 
open attempts. RM interface. Comdeck FA=OPE. 

bb. FAfRDC. Read coded line. Transfers coded line to 
working buffer. RM interface. Comdeck FA=RDC. 

cc. FAfRDW. Read words to working buffer. RM interface. 
Comdeck FA=RDW. 

dd. FA-RWX. Rewind file. Suppressed for scratch files. 
RM interface* Comdeck FA=RWX, 

ee « FA=WTH. Write coded line. To a file. RM interface. 
Comdeck FA=WTH. 

ff. FA=WTW. Write words. From working buffer to 

sequential file. RM interface. Comdeck FA=WTW. 

NOTE: Only the CIO or RM I/O routines are assembled, 
depending on the system. 
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2.3 PUC: Program Unit Controller and Support 

6kS±r.&£L±: PUC contains data and routines of a general 
nature, which are required by ail (or most) 
overlays. Performs program unit 
initializations. 

InifiLf SCfiS • Contained in all overlays. 

ya±a_5±LU£.±Li£e.& 

Data structures of PUC are mostly communication cells, 

**s»sw i ui inTwi His t* «ri w nun i cos voiiuiL7 fur Trie uursxion 

of a program unit. 

^. Xd&l&S.* A series of cells (four tables), used by the 
table manager (and any routine which accesses the 
managed tables). Provides entries T.xxx (table FWA) , 
T=xxx (table size) and associated tables regarding the 
growth rate of individual tables and (test mode) table 
names for the IDP interface. Comdeck COMSTAD is used 
to provide table information for CCG shared tables. 

*>. Lfltal-BiflcJi^Iaklfi. Local block ordinal table. Used 
by code generation, assembler, etc. Provided by 
comdeck COMSLBT. 

c. QQiuaiaQ^Qfills - These are flags and indicators which 
reflect the current state of the compilation. The 
cells here are typically things which must survive 
secondary overlays (OPT>0) and that pertain to front 
end/code generation/assembly. There are also working 
copies of control statement option cells which may be 
altered by C3J directives. 

A CKnn+ /"*<•% »ij= +=»« + *- A 4iikl n «.£ — ~_»~_.~ 1 ».. . . _ _ J _ I- j. 

- " UUKUxJiHUAJAlUa • «~» *.«■!/*« wT «_ UIIUIIU1 IX f U3CU SilUC (. 

constants (e.g., 0, .true.) in TP. format. Used by 
front end processors mostly, but some have CCG 
interface application. 

e. Ea.-.SQBD- A table of symbol table ordinals for symbol 
table entries made by the compiler as part of the 
initialization process. 

f- EBBIY.E- A table of diagnostic message labels used by 
front and rear end diagnostic production. 

g- Ejl-.£I&- Instruction description vector. A table of 
COMPASS CPU instruction templates, used in formatting 
object listing and determining instruction form. 
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Routine Descriptions 

a. PUC. Program Unit Controller- PUC is entered after 
overlay initialization and provides some startup 
processes and directs the flow of compilation- 
Functions include: setting up the listing pagination 
for the current program unit, clearing the compiler- 
scratch files, determining if the program unit is a 
FORTRAN or COMPASS coded routine <if COMPASS, transfer 

4-n I n/TlM £. •■» ri PrihDACC m na% r\ 1 =i w 1 n .s s<i * «r m^Ais. \ sir\ A 

IU uuwuri i wi uuin r-T%_Ji_f uvci j.a^ j.wdu x => uiauc / biiu 

successive calls are made to the front end, code 
generator and rear end loaders- (Whether actual 

A uau A iiU AST faF St; a i ui jueu >x. 5? « zwtssw'k.a.wis w j -w * a s~ -wi 5 a i— » w a n j 

Upon completion of compilation, PUC computes some 
program unit statistics and outputs such things as 
memory used and error totals. 

b. ENDFTN. Terminate compilation. Performs final 
housekeeping chores upon completion of compilation, 
outputting dayfile messages, turning off SPY, etc. 
Contains abnormal termination code and code to 
initiate binary execution when the GO option is 
present. 

c- CPTIM. Computes elapsed CPU time (via call to TlrO?) 
and converts result to DPC. 

<*• IIt!iB« Tr,e routine which interfaces the system clock 
and converts elapsed time into milliseconds. 

e- WE£- Wait File Actions. The CIO interface wait 
routine. 

f. CFD. Convert an integer <30 bit) to display 
floating. Comdeck COMCCFD. 

9- QAF. Close All Files. Called by PUC upon compilation 
finished. Performs cleanup function of closing opened 
files and eviction of compiler scratch file. 

h. CQF. Close output file. Called by CAF to reset print 
density (if necessary) on sequential output files. 

i a ECB = Evaluate constant character bias* Using symbol 
table information, ECB calculcates the actual bias for 
constant character array subscription. Comdeck 
COMFECB. 

j. ECS. Evaluate constant substring. ECS calculates 
bias and substring length for constant character 
substring references. Comdeck COMFECB. 

k. GCL. Get character length. GCL extracts the 

associated length attribute for type character symbols 
(or if assumed length, the VD. tag for the defining 
length) . 



B_3-9 



1. GMC. Get More Core. Provides system interface for 
MEM requests when current FL is insufficient fop 
managed tables. If the maximum FL has not yet been 
attained, a provided (user) increment is requested 
from the system. 

m. LJS. Left-justify statement label. This routine is 
used by diagnostic production and rear end listing 
routines to adjust and space fill statement label DPC 

ronnocon + a+Jnn_ I TQ ic noroccarv herAiicp n«P +h*a 

symbol table format for label names (right justified). 

v\m MTD- Move Tables Down. MTD compresses the contents 
of the managed table area into the low core portion of 
the managed table area. Used by the FTN5 (not CCG) 
table manager for reallocation and by CCG. 

o- t-JTU- Move Tables Up. MTU compresses the contents of 
the managed table ar&a into the high core portion of 
the managed table area. Used by CCG. 

P- EI£- Process instruction address. PIA converts a 
binary number to octal DPC, with leading zero 
suppression and a 'B' suffix. Used for object listing 
address fields and wherever this type of conversion is 
needed. 

q« £§__§■ Print error summary. Loops through error 

count information, producing listing of error 
counts by error level. Output to console and 
dayf ile. 

r, PCS* Print Core Statistics. Output the current FL 
used by the compiler. Called when a MEM request is 
made. 

s. WHL. Write Header Lines. WHL is called by WOF when a 
new page of listable output occurs. Performs some 
conversion and template plugging prior to outputting 
the header. 

t. WOF. Write output file. The standard interface to 
the coded output routines (UTILITY). WOF determines 
the nature of the request, precedes the output with 
blank lines as required, determines if page size is 
exceeded (and increments pagenation information and 
calls WHL) and passes the output information to the 
relevant system interface routine for output. 
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2.4 Linkage Decks jf? 

FTN5 utilizes common front and rear ends which send input 
to and receive output from two dissimilar code 
generations: QCG and CCG. 

The differing overlay structures (Sect. A, 1.0) force 
different control flow methods for the two code 
generators. Typically QCG is loaded as one overlay and 
remains in core for the duration of compilation while CCG 
loads successive secondary overlays for phase transition. 
The two code generators require some differing information 
and processing. This can involve different processing 
routines to perform the 'same 1 function. 

In QCG mode, the presence or absence of the map and object 
listing routines change requirements for routine calls. 

To keep the front and rear ends truly common? the system 
of link decks was devised. Where functions are needed by 
one but not both code generation modes* the function is 
placed in both link decks. Where the function is 
required, code to perform the function is provided. Where 
the function is not required? a stub is placed? providing 
a 'do nothing' subroutine. This allows the common 
portions of the compiler to just request the function, 
regardless of code generation mode, and also allows the 
overlay which didn't require the function a core savings. 

The linkage routines vary from overlay to overlay, and 
technically are not really cradle routines. But since at 
least one link routine is present in every overlay 
structure, the routines logically belong to the cradle set, 
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5.4.1 GCGLINK; QCG Mode Linkage 

Abst ract; GCGLINK provides stubs and routines for the 
QCG code generation mode. 

Interfaces; GCGLINK is part of the (0,0) and (1,0) overlay 

Data Structures; None 

Routine Descriptions 

*" L-fci=" ' » vJiii. i_ii\j i_uauei . inu lUdOlIig fltTUfliiy 

performed. Transfer is made to FEC and an entry point 
is provided for return. Provided for compatibility 
with CCG which requires a load of front end routines. 

b- CGE; Check code generator errors. Stub only. 

c - DER« Detect extended range do loops. Stub only. 

d. LPE; Link possible entry do loops. Stub only. 

e. MDD; Mark do parameters defined. Stub only. 
*■ EQ£- Process divide by constant. Stub only. 
9- !,CT; Blanch constant table. Stub only. 

h. MAL; Mark loops entered. Stub only. 

i. PCA: Process CAC table. Stub only. 

j. PAT; Preprocess A-P list table. Stub only. 

k. CGL; Code Generator Loader, Stub only,, Tn QCG mode 
generation, code generation is performed concurrently 
with front end processing,; thus, no need for a 
transfer here. 

1. REL. Rear End Loader. Again, no load, just 

transfer. If the prebinary file is still in core, it 
is flushed to disk for CCG compatibility. An entry 
point is provided for return. 

m - EQI : Publish data to IL file. The QCG version copies 
DATA statement output from T.DATS to the prebinary 
file (table or file). 

n - EIi= Publish IL Segment. The QCG version calls CAI 
to compile instructions to the prebinary file (table 
or file). 
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E. 4.5 CCGLINK: CCG Mode Linkage ■" 

6k£±E.acJt: CCGLINK provides routines specific to the CCG 
mode overlay structure. 

lQ±£L£a££ : CCGLINK resides on the (2,0) overlay. 
A table of CCG linkage values is provided. 



r-» 

rx nil t -» 
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a. EEL: Front End Loader. Calls the overlay loader 
processor to load the (2,1) overlay. Provides an 
entry point for return from front end processing. 

b. ££L: Code Generator Loader. CGL prepares the managed 
table area for use by CCG. If the cross reference 
file is still in core, it is flushed to disk. The 
overlay loader processor is called to load the (2,2) 
overlay. An entry point is provided for return. Upon 
return, managed table pointers are updated for rear 
end processing. If syntax errors occurred during 
front end processing, loading of the (2,2) overlay is 
suppressed. 

c. BEL: Rear End Loader. The prebinary table is flushed 
to disk and the overlay loader processor is called to 
load the (2,3) overlay. An entry point is provided 
for return. 

d. Mfil: Move all tables. Called by CGL to reformat the 
managed table area for CCG. MAT preserves tables 
"nidi mus v survive r*oni en« *.o rear end. Common 
tables front end - code generator are relocated. All 
other tables are trashed. 

e. UIE: Update Table Pointers. Reverses the 
transformation of tables common to front end - code 
generation performed by MAT. Tables are now in a 
usable form for rear end processing. 
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5.4,3 ZEROLNK: 0*0 Overlay Linkage 

6k£±L££±: ZEROLNK provides stubs for routines pertaining 
to map and object listing* which are not 
present in the (0*0) overlay. 

Il2±£L£a££S.: ZEROLNK resides on the (0,0) overlay. Its 
purpose is to allow a common rear end 
regardless of output listing parameters. 

Qa±a_5±r.U£±m:£s. : Non e 

Bflu±in£_Qs££Hia±iJins 

The following routines are all stubs. 

a. E.IK* Print instruction conversion. 

b. H6E: Map listing. 

c. LU3: List Unit Statistics. 

<*• ElUt EIbLM6E* ElbLQL: Entry points to provide pseudos 
for the LWA of the overlay. 
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2,4.4 RLINK: Rear End Linkage, 
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6kS±E.a£±: RLINK provides routines, stubs and data 

structures for the rear end processor in a CCG 
context. 

Ia±£C.£fiIL££ 2 RLINK resides on the (2*3) overlay. 

Qa±a_£±E.u£±LLC£s. 

The data structures described below are used to transform 
CCG output into a format understood by the rear end 

a. BH* Register Translation Table. Conversion matrix 
for CCG coded register designations to actual register- 
numbers. Used by CI I. 

b. HTT: H field translation table. Used by CII. 

c. QBBQEES: CCG IL instruction definitions. A table 
used for converting CCG IL into machine instruction 
(prebinary) format by CII. Comdeck OPRDEFS. 

BQU±iaSL.Q£££rJLE±iflQ£ 

a. LDB: List Deferred Buffer. A stub- which in test 
mode provides a blowup if action was to have been 
taken. 

b. £££. Check code generation errors. The code 
generators have no diagnostic capability in FTN5. 
CCG- however, does diagnose some error conditions. 
This interface uses the rear end diagnostic capability 

4.— M . . J,... u. ...... . .... .....^..w u«- r*r*r+ 

cu uu iku *. mcaaayca re^uiieu uj \*w\j ■ 

c. CXI- Convert Issued Instructions. This routine 
transforms the CCG intermediate file code into 
prebinary format required by the rear end processor. 
Processing is performed for one instruction/code at a 
time . 

d. BQIS Convert constant table. The CCG constant table 
is converted from bias arrangement into the actual 
constants (T.CUT to T.CON transformation). Unused 
constants are eliminated. 

e. £EE: Check Formal Parameters. Used by CII to process 
formal parameters in the CCG IL - prebinary 
transformation. 
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f . 3BEU Set materialize bit- Stub only. 

9- E6I: Process AP-list tables. A transformation of 
CCG. AP-list constants into prebinary form required 
by the rear end processor. 

h. E£&: Process character address reference constants. 
Transforms T.CAC from the CCG constant style to the 
prebinary form. 

i- SCS: Scan table with supplied mask. This routine is 
used by front and rear ends? not by code generator, 
ion £„ ^ SCH F££ a (J- coni< j ec i < cor*FS€8. 
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2.4.5 LISTLNK: Listing Linkage |{§ 

&k£±£.a£±:: LISTLNK provides the program unit statistic 
output routine. Exists to save space in the 
(0*0) overlay. 

in±ar_£a£.as : LISTLNK appears where program listings are 
required and resides on the (1,0) and <2 f 0) 
overlays. 

Qala-.31r.iAC.lur.fi" Program Unit Statistic template. 

Esulinfi_ysm&r.i£liim : 

LUS- List Unit Statistics. LUS is the subroutine called 
by PUC to provide the calculation and formatting of final 
program unit statistics. Functions include converting 
binary values to listable DPC> formatting variable data 
into the statistic template and calculation of some values 
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2.5 PEM: Print Error Messages 

Abstract: PEM accepts a diagnostic request, and if 
output is required, formats the text and 
outputs the diagnostic. 

Inl££f§££s: Diagnostic processing is provided only for the 

r t. t t -. _— -! -ri rsrrM i— __^,.t._.:.^,.,j 

num. tsnu anu real* euu. tnus rcri its uuiildiiicu 

in the (0,0), (1,0), (2,1) and (2,3) 
overla v s= Although not a 'nure' cradle 
routine, PEM is considered universal enough to 
be included with those routines. 

Data Structures 

The following data structures are used by PEM. All are 
described elsewhere. 

a - AsseTnbiX-QoQsimi-Ilklf:- Described in FERRB. 

b. ERRSKEL: Diagnostic skeleton definition, described in 
FERRS. 

c. ERRTYP: Described in PUC. 

d. The actual error texts are described in FERRS. 

e. CHARMAP: Described in FEC. 



B2y±iO£_Qsscri£ti.ons 

a " ANSI- ANSI diagnostic blockage. This routine is a 
filter used to stop processing of ANSI diagnostics 
when they are not required. Switch is set based on 
control statement parameters. 

t>» MQ§BB : Machine dependent diagnostic blockage. Works 
exactly like ANSI. 

c. PEM: This routine has three flavors, depending on 

whether variable text information is to be processed. 
PEMS is an entry used to process cells FILL., FILL. 2, 
FILL. 3. All three cells are assumed to be preset in 
L format. PEMS determines the length of the 
information string in each cell, and appends the 
applicable length character. PEMV assumes FILL, is to 
be set with the current contents of the token buffer, 
up to 10 characters. A transformation of tokens into 
characters is made, using CHARMAP, until 10 characters 
are obtained, or the end of the token buffer is 
encountered. 
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When PEM proper is entered, all variable information 
has been formatted. The error level of the current 
diagnostic is determined, and a count of diagnostics 
at that level is incremented* The control parameter 
error level cell is checked to see if this diagnostic 
need be printed- If so, the proper prefix label is 
selected and moved to the buffer area. Each 
diagnostic word is fetched in turn, its iSny vn 
determined, and the proper number of characters are 
maprtaA into the buffer* In some cases* tvaop width 
will require splitting the diagnostic into two lines. 
PEM handles this- Upon completion of the buffered 
build, the diagnostic is output to OUTPUT/ERRS file(s), 

d. PDM: Print diagnostic messages. FTN5 has two types 
of diagnostic return. One method is a provided return 
address. The second is an implied return. PDM 
provides the mechanism for the implied return. PDM 
fetches the PEM entry relevant for the diagnostic and 
jumps to that return. The diagnostic return is set 
for PDM, which in turn returns to the caller. 

e. UEC: Update error count. Used by PEM to calculate 
and update error counts. Also processes possible 
error termination cases. 

*- SVR/RSR: The decision was made to save all registers 
when processing diagnostics. The overhead was felt 
justified by the freedown allowed the routines using 
the diagnostic processor. SVR- and RBR- save and 
restore all registers. Comdeck COMQSVR. 
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ALLOC; Table Allocation (Managed Tables) 
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6&£±La£±: ALLOC is the managed table manager for the 
front end and r&ar end. 

lG±£E.£a£L£S. : ALLOC appears in overlays (0,0), (1,0), (2,1) 
and (2,3). It is not a 'pure' cradle routine, 
but is fairly universal. 

ALLOC operates on two data structures: table pointers and 

a. Iakla-EflinlfiLS.: The table pointers consist of two 
tables of cells, T.xxx which gives the FWA of the 
table xxx, and T=xxx which contains the length of 
xxx. A pair of these cells exists for each managed 
table. 

b. Iakl£&: The managed tables are in high core. The 
starting location varies with various overlay 
structures. In general, the core used for the 
initialization decks (INITyy) is available for managed 
tables. The end of FL delimits the table area, 
although this limit may be extended by MEM requests. 
The managed table ar&a and relationship to the 
pointers is depicted below (Fig. 2.1). 
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Figure 2.1 
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Bau±ins-QsscxiE±ians 'v.. H1Z 

a. &Qy: Add word. Calls ALC to obtain a word for the 
required table- Stores the datum into the space made 
available. ""* "" ""*""*""" ™ —-——■" 

b. &L£: Table manager and allocator. This routine 
should always be called to add any data to any managed 
table. Disasters can occur if this rule is not 
observed. 

ALC is passed the table to allocate and the number of 
words to extend the table. If there is sufficient 
available space following the table being allocated, 
the length of the table is updated and ALC is 
through. (Check listings for return conventions.) 

When space is not available, a table crash has 
occurred. The managed tables are compressed and then 
reexpanded, reallocating the available space. The 
amount of free space left between tables during the 
reallocation is dependent upon the table in question 
and the current processing state of the compiler. At 
various points in front end and rear end processing, 
registers are used as table pointers. ALC supports 
this madness by allowing up to one lack register. If 
a lock register is used, the register contents is 
converted to an offset into the associated table. 
Upon completion of allocation, the offset is converted 
back to an address. 

If sufficient room in the managed table is not 
available, GMR is called to try to obtain the room. 
It will do so, or abort the compilation. Concurrent 
with moving the tables around, the T.xxx table is 

. . _ «4 -t4.~ .J 4.~ ..£l..x J.U — _..____j. _ J. _ j. _ _r J. i i il. .2 -I..-1 

uK«avcvi tu rsneti cue uuitciil stdie ur uie niaiviuucli, 

table FWAs. Upon completion of the reallocation, the 
T.xxx reflects the state of the managed table area f 
and the specific T=xxx has been updated with the 
additional allocated space. 

c. £C3B- G®* More Room. GMR is called by ALC when there 
isn't sufficient managed table space to satisfy the 
current request and to allow space for expec±ed 
allocations in the near future. GMR first tries to 
obtain the necessary space by flushing some tables to 
disk files. If that is not sufficient (or has already 
been done), a call is made to GMC to make a MEM 
request. If the MEM request is disallowed, but the 
current allocation was satisfied, Grtf? will return and 
attempt to continue compilation. If the specific 
request is not satisfied, compilation is aborted. 
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<*■ EI&S Print Threshold Alarm. Called by GMR when a 
specific allocation was barely able to be satisfied, 
no more MEM are allowed- Test mode only. 

e- BIS: Print table statistics. Test mode debug device 
to track table crashes. When table crash occurs, the 
table being allocated and status of the managed table 
area are output. Selected by the SNAP=T control 
statement option. 
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2.7 Snap Interface Routines 

The snap routines provide interface to IDP (interactive 
debug processor) and format table dumps and snap output. 
There is a separate routine for the front end* CCG and 
rear end processors to provide the formatting needs of 
these processors. The snap routines are test mode only. 
These decks/routines are not true cradle* but one of the 
routines appears in every test mode overlay. 



WU 
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5-7.1 FSNAP - Front End Snap Package 



&k£±£.a£±: FSNAP provides IDP interface and dump 

formatting for the front end processor and for 
single overlay processors. 

lQ±££.i££££ : FSNAP interfaces heavily with IDP, and the 

break mechanism therein. It appears as part 
of the (0,0) , (1,0) and (2,1) overlays, test 
mode only. 

a. CQC33IQE: IDP interface macros, micros and 
definitions. Described in the IDP deck (2.7). 

b. QQdSQQfi: Quick code mode structure definitions. Used 
for formatting dump information. Described in QCGC 
deck (4.1). 

c. £QC33IQ&2 Data structures and routines pertaining to 
token generation. Used in formatting snaps of the 
token buffer. Described in LEX deck (3.3). 

<J- Q±u££.: Other data structures are described with the 
routines that utilize them. 



Rau±in£_Q£££xi£±iojis 

a. £IC&: Convert token type to DPC. This routine takes 
the token type passed it, and returns the 
corresponding DPC of the token. Performed via table 
lookup in CHARCMAP (described in deck FEC (3.1)). 

K CTU« Cnnm-%4- 4--.kln W * -.. J i -~. ~ D__.C~.._>_ X _ U 1 _ 1 I f 

«* ■ liu> « w« ««H=i *- w«*/^«? ncguiiiy • reiTuiiiia i«av it? iuukuk rur 

table names, origins and sizes. (NAMES, BASES, SIZES 
in PUC (2.3)). The binary numeric data is converted 
to octal DPC. Used when dumping a table. 

c. LIB: List token buffer. An interface routine for LTK 
(list tokens). Saves and restores registers and 
informs LTK of the nature of the request. 

d. SfcLECII- Snap emitted turples. Formats output for a 
single output turple (front end format). Call the 
formatters for the turple header and turple operand 
(twice) . 

e. 5NfPARs Snap parse file. Similar to SN.EMT, except 
that the entire contents of table T.PAR are 
formatted. Action provided by SN.EMT is performed in 
a loop. 
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f- 5fcL£5Yd: Snap parse file symbol. This is the v 

formatter for the operand fields of a turple. Breaks 
the TP. format into component parts and formats for 
output the DPC (if symbol table entry) or octal DPC 
(intermediate or short constant) as well as mode and 
other information. 

g. SfcLEQE- Snap parse file operator: The formatter for 
the turple header (operator) word. Breaks the TH. 
format into component parts and formats DPC of the 
operator , turple mode and the status of the operands. 
Both SIM. POP and SN.PSYM utilize output templates into 
which the DPC format information is plugged. There 
are also small tables of DPC values for mode and 
operand information. 

h. Q6I: Dump a table. Interface to IDP core dump 

routine (DCM=). Formats table lengthy name and origin 
for header. Determines if symbol table is to be 
dumped and selects either DCM= or DSY for the table 
dump. Comdeck CQMDDMT. 

i- QdXr- Dump tables. The driver for DAT. Determines 
how many tables are to be dumped* and successively 
calls DAT for each table. Comdeck COMDDMT. 

j. Q3¥: Dump symbol table. Formatter for dump of symbol 

table. Breaks up the symbol table WA.y WB. and WC. 

words into segments as defined by those formats. 

Provides a DPC and octal DPC mixture of formatted 
information. Comdeck COMDDMT. 

k. QQdDIQti: This comdeck contains routines and 

structures used in producing tokens from source. 
FSNAP uses the routine to disassemble tokens to 

provide T»n«iK ut lurch uuttbii incr ucawi if t.4uu t w« 

COrOTOK routines and data structures is in LEX (3.3). 
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2.7.2 CSNAP: CCG Bridge Snap Package 

6k£±£L2£±: CSNAP provide IDP interface and dump 

formatting for the CCG/Bridge environment. 

InifiCfaSLas: CSNAP interfaces IDP and the break mechanism. 
Resides on the (2*2) overlay* test mode only. 

CSNAP utilizes COMSIDP, described in IDP (2.7). 

CSNAP utilizes the following COMDDMT routines* described 
in FSNAP (2.6.1). 

a. DAT 

b . DMT= 

c. DSY 
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2.7.3 RSNAP: Rear End Snap Package 19 

&k&±F.a£±: RSNAP provides IDP interface and dump 

formatting for the rear end processor in the 
CCG environment. 

lQ±££.£=a£.e.S.: RSNAP interfaces IDP and the break mechanism. 
Resides on the (2*3) overlay? test mode only. 

Qaia-Slnutimifis 

RSNAP utilizes COMSIDP, described in IDP (2.7). 

Bau±iii£-Qss£ci.&±iaas 

RSNAP utilizes the following COMDDMT routines, described 
in FSNAP (2.6.1). 

a. DAT 

b . DMT= 

c. DSY 
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2.8 IDP: Interactive Debug Package 
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Abstract: IDP consists of common routines/structures 
used by ail products/programs which utilize 
IDP and FTN5 specific code for compiler 
interface to IDP- IDP users are re-f-erred to 
the IDP reference manual. 

lQ±£r_£a£S : IDP (the deck) interfaces IDP (the program). 
IDP usage is beyond the scope of this 
document. IDP resides in the (0,0) , (1,0) and 
(2,0) overlays, test mode only. 

Qa±a_3±nu£±uc.ss 

a. QQ&6IQ&: Token generation language macros. Described 
in LEX (3.3). 

b« CQHSIDE- This IDP provided comdeck contains macros, 
micros and structure definitions used by IDP and 
interfacing routines. It serves the function of a 
text, but is assembled as part of routines which 
require it. Macros include those for generating 
keyword (IDP) tables, entry tables, formatting routine 
parameter set up. IDP symbols are defined here. 

c. CQE33IQK: Data structures and routines pertaining to 
token generation. Described in LEX (3.3). 

d. QiufiE.: Other structures will be described with their 
pertinent routines. 



BQu±in£_Q£sxni£.±io.i2& 

«« JdLL^asLi. • r-iuui u lur. nesiure rggisters «mq evone 
system abort. 

b. QXE: Dump exchange package. Compiler specific. 
Provides a NOS/BE like dump for SCOPE 2. Needed 
because SCOPE 2 has no reset, and the register dump is 
the status of the register after reprieve. 

c. EIQ: Print table origins. Compiler specific. 
Formats managed table information for output. Outputs 
the information, including a list of pseudos applying 
to each table. 

d« IEXS Transfer exchange package registers. The 

contents of the saved exchange package (registers) are 
moved to the COMCSVR save area. Restore of registers 
is then from the saved exchange package. Compiler 
specific . 
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e- UXQ* User IDP owncode. Compiler specific. 

Interfaces IDP break request. If a new overlay has 
been loaded since the last IDP calif the break point 
table is cleared. (An IDP call is executed at each 
overlay load [when in BREAK model for this purpose.) 

f . UBQ: User IDP register owncode. Compiler specific. 
URO selects or deselects register snaps* based on 
requested snap option information. 

9- USQ: User IDP snap owncode. Compiler specific. USO 
selects or deselects core snaps* based on requested 
snap option information. 

h. LEY: User IDP symbol search. Compiler specific. USY 
provides access to an IDP symbol search routine. An 
RJ is constructed to the search routine* which is 
overlay dependent. 

i- LECU Local file manager. Provides system interface 
to PPU program for file management. Comdeck COMCLFM. 

J- £Q£i£IQE: This comdeck is the interactive debug 

package proper. Routines and structures described 
here are not under project control 

1 > S±CU£±ux£S 

&QB5BJ: Return address of calling routine. 

&£L: IDP parameter list, from the IDP call. 

SQ5BB&Q: Previous contents of break address. 

EaBDQ: FET and buffer for batch debug output. 

EiJ£LL: Line image FET for interactive debug input. 

EaIDQ- FET for interactive debug output. 

EWjlSUB: Register save area. 

IQEL&fi: Coded flag giving information about 
current break/snap request. 

Ekk£QI- Parsing operator/operand table. Used by 
IDP to parse expressions in IDP requests. 

E1£a£dSl: Parsing stack. Used for the shift 
reduction of operators during parsing of 
expressions in IDP requests. 
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EIsLlBEN: Reverse Palish stack. Used -For operands 
and reduced operators to form reverse Polish 
notation used during parse of expressions in IDP 
requests. 

Sl^fiUiJE* Output line image buffer. 

£fills: IDP provides a large group of internally 
used storage cells to provide flags, status 
information and values used by IDP in processing 
requests. 

IQ=: User/token generation communications area, 

EfeLSGI: Statement control token table. 

B&^KEY.: IDP keyword table. Used to drive 
processing of request parse. Broken into IDP 
commands r break commands f step commands? and has 
associated subkeyword table for step and output 
options. 

EWj.ESB: Diagnostic texts for IDP messages and 
FW.SER system errors. 

IQEBA: IDP break address and break contents 
IQEBC tables. Parallel. 

IQEIdE: User temporary table. 

IDE3EI: IDP set value table. 

IDEXEI- IDP most recent transfer address table. 

2> Bauiinss 

UEB: IDP freeze recovery/restart. This really 
isn't a routine. It is copied to the file F.FRZ 
as the first record when restart is required from 
a freeze requested by the host program. The 
routine is executed by transferring control to the 
F.FRZ file. 

3¥3: System request interface routine. .. Processes 
system calls. 

Bfclbl: Read host into hole. Reads a frozen host 
from F.FRZ into the hole created by IFR. IDP 
processing continues. 
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IDE! The interactive debug routine. This routine 
controls the processing of IDP requests- When IDP 
is entered for the first time? initialization is 
performed. Afterwards? this initialization is 
bypassed. The IDP user requests are then 
processed as they are encountered and the proper 
processing routines are called. After completion 
of the request » control is returned to the user. 

BE£: Register snapshot. REG provides an octal 
DPC dump of ally or selected? register contents. 



Gore and register snapshot. £3*4P provides an 
octal DPC dump of selected core locations and 
requested registers. 

3Cs2 Selection control routines. Provides small 
utility routines which process brief mode toggle 
switch, output diagnostics? process ABS 
directives? process break directives? process code 
directives? connect files? process DPC directives? 
disconnect files? and processing of requests? 
freeze processing? jump address processing? option 
processing? output processing? register dump 
processing? REL directive processing? SET 
directive processing? SNAP directive processing? 
status processing? STO directive processing? step 
mode processing? unbreak processing? unset 
processing? WHERE directive processing? XFER 
directive processing and STRN directive 
processing. All these routines are called by IDP 
when the directive indicated is encountered. 

6QZ: Add word to IDP table. ADZ searches the 
indicated table for the required entry. If not 

ruuny f k.\\xs ncrw euiry im indue Siiu tns end or XclOie 

indicator is reset. 

BB&: Break processor. The routine is called when 
a break point is encountered during execution. 
Interfaces to IDP for directive request processing. 

£6Q: Convert address from binary to octal DPC. 
Used by several IDP routines. 

£££: Check Break Condition. When BRK is entered? 
CBC is called to check if the break condition was 
met. If so? break processing commences? 
otherwise? BRK will revert to caller. 

QJtM.1 Check memory address. Determines if the 
indicated address is accessible by the user. 
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QIB- Convert integer to binary- Converts a 
string of DPC digits (decimal or octal) to binary 
representation. 

QLZ" Clear IDP table. The indicated I DP table is 
cleared to all space available indication* 

£Qfcj: Connect/disconnect file. System dependent 
interface to connect or disconnect IDP files. A 
flavor is provided for SCOPE 2, NQS and NOS/BE. 

£31: Classify statement. Used by IDP to match 
user directives with the keyword table. This* in 
turn, determines which SC= routines are invoked. 

QXRZ Check executive RJ. CXR determines if the 
IDP executive request had a parameter list* and 
returns its address if one is present. 

Q£B: Dump A or B register. Service routine to 
format contents of A/B register and the contents 
of the address pointed to by that A or B 
register. Called by DAR and DSR. 

Q6B: Dump All Registers. Produces the formatted 
register dump for all registers. 

Q&Z: Disassembler. For CODE directive requests. 
Treats binary as if it were code* and produces a 
mnemonic assembly listing for the area requested. 
Uses the table DAZ=PS for formatting the output. 

BQj: Dump Central Memory. Converts binary to 
octal DPC for the area of memory requested. Used 
for most table dumps and snapshots. 

QQQ: Dump central memory, octal and DPC. DOD 
provides two output representations at central 
memory: octal DPC and alpha DPC. 

DSB: Dump Selected Registers. DSR provides 
register snapshot, as per DAT, but only for 
registers requested. 

QUX: Dump X Register. DUX dumps the octal DPC 
contents of a specified X register. Called by DAR 
and DSR. 

E66: Find Absolute Address. Converts address 
requests of the form 'deck' + offset into an 
absolute core location. A user provided deck 
name/address table entry is used. 
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E6S" Format A or B register. Used to format the 
contents of an A or B register. Called by DAB. 

ELL: Check FWA, LWA and length parameters. FLL 
tests the legality of the named parameters on any 
IDP request where they are present. 

EQE: Flush Output File. FOF conditionally 
flushes an output file, depending on the contents 
(or lack of contents) of the buffer. 

E&&: Find Relative Address. Opposite routine to 
faa. Takes an absolute address and converts it to 
the form 'deck* + offset. 

ER&: Check frequency parameters. FRK keeps track 
of the number of times a particular request is 
honored and compares with the increment value. If 
at an increment? the snap is honored, else control 
is returned to caller. 

EBZ: Freeze interactive session. Initiates the 
freeze which IFR eventually restores. 

Q.1L' Generate Indirect Load. Processes indirect 
loading to the desired level of indirection. 

fcfl2&: Print snap header. Outputs the formatted 
header line indicated. 

IEX: Initialize executive. Called when 
processing an IDP request. Provides 
initialization required for all requests. 

HE: Initialize Interactive Files. 
Connects/opens IDP files. 

131: Initialize Set Table. Initializes IDPSET at 
start of overlay session. 

LSI: List Break Table. Provides a DPC octal 
listing of current break points set. Form is 
'deck' + offset, opt, opt, ... 

LSI: List set name table. Outputs set names and 
values currently active. 

LXI: List transfer table. List contents of 
IDPXFT. Octal DPC. 

tSJL: Integer multiply. Provides a GO-bit result. 
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E63! Parse subexpression. The parse routine for 
expressions in IDP directives. The expression is 
parsed (shift reduce) into a polish string, which 
is then evaluated, returning an absolute value. 

Rial: Parse FWA, LWA, LEW triple. PAT makes 
successive calls to PAS to evaluate the indicated 
parameters. 

nrTKrt . o— i _ -l. rr_ _ _ _ iut r-n—wj . _• j_l 

CfcU" rrun crt'ur rie^^csge. run converx5 xne 

diagnostic pointers into dictionary words and 
formats the diagnostic line for output. 

EQLS Process options list item. POL is called by 
IDP SC= routine to process a list item. Uses the 
required subkeyword table for the request. 

EI&- Pointer manager. PTR manages the access and 
updating of user interface pointers. 

BIL« Read IDP input line. Under control of 
status flags, reads IDP directive lines into a 
buffer for translation. 

BOL: Write output line. Utility to provide IDP 
an output mechanism. 

3&I: Search keyword table. SKT is a routine 
called by CST to actually search the table for a 
command verb. 

SLES Search for logical file name. Searches for 
a user supplied LFN through the FET/FIT table and 
FA.SSW. Returns FWA of FET, if found. 

SQB - £»*»+ nn+nii+ *1ja« K-i+e nn+nn+ K4+«= £«rt k^^rk 

listing control are set to differentiate between 
batch and interactive modes. 

S3Y.: Search Symbol Tables. Searches IDP ' s 
various symbol tables to associate a binary value 
with a DPC name. If found, a code is returned 
denoting type of symbol (deckname, set symbol, 
user symbol, etc.). 

SIE: Step an instruction. STP steps a single CPU 
instruction and lists result register as 
necessary. Called when step mode is invoked, for 
each instruction of the step range. 

IQGELZIQ&- Token generator for IDP request 
processing. Contains token skeleton macro calls 
and token generation routines. 
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LfiK" Unbreak. Removes indicated break and I lu 
restores user code at that point. 

UEQ- User Freeze Owncode. Interface to user 
provided freeze processing. 

LEB- User freeze restart owncode. Interface to 
user provided freeze restart/restore code. 

UXQ> User IDP owncode. Interface to user 
supplied IDP executive. 

yfjy; User REG owncode. Interface to user- 
supplied register dump routines. 

U3Q« User SNP owncode. Interface to user 
supplied snapshot routines. The five user 
interface routines utilize 'soft 1 externals and 
are satisfied either by the user, or by canned IDP 
routines. 

y&Bl Process variable token: used by TQGEL/TOK 
to special process entokening of variable names. 

k. BUB- Burst/build characters with blank squeeze. 
Burst an input line into individual characters? 
trashing blanks. Used in entokening IDP requests. 
Comdeck COMCBUB. 

1. BUbU Burst characters, no blank squeeze. As BUB* 
with no characters eliminated. Comdeck COMCBUN. 

m. £QQ: Constant to decimal conversion. Comdeck 
COMCCDD. Described in UTILITY (2.2). 

n. i^AU- i/u runcxion processor. uomciecK uunuuiu. 
Described in UTILITY (2.2). 

o. QQQ: Convert constant to octal DPC. Comdeck 
COMCCOD. Described in UTILITY (2.2). 

P. QXB: Convert DPC to binary. Comdeck COMCDXB . 
described in UTILITY (2.2). 

q« d£32 Merge Coded Strings. Concatenates zero filled 
strings into a new string of up to 2 words. 
Trailing : (64 character set) ar& lost. Comdeck 
COMCMCS. 

r. BQ£: Read Coded line. Comdeck COMCRDC. Described in 
UTILITY (2.2). 
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s. BOMS Read words to working buffer. Comdeck COMCRDW. 
Described in UTILITY (2.2). 

t. BQ&: Read exit. Comdeck COMCRDW. Described in 
UTILITY (2.2). 

u. L£B: Load Circular Buffer. Comdeck COMCRDW. 
Described in UTILITY (2.2). 

v. S5E« Restore all registers from a specified save 
area, Comdeck COMCRSR. 

w. gig: Set block of memory. Comdeck C0MC38M. 
Described in UTILITY (2.2). 

X. 5E&Z Space fill name. Comdeck COMCSFN. Described in 
UTILITY (2.2). 

y. SyB: Save registers in a specifier register save 
area* Comdeck COMCSVR. 

z- SYS: Process system request. Comdeck COMCSYS. 
Described in UTILITY (2.2). 

^' CQ&CIQ&- Routines and structure used in entoken IDP 
requests. Described in LEX (3.3). 

bb. yQQ: Convert word to octal DPC. Comdeck COMCWOD. 
Described in UTILITY (2.2). 

cc. yiQ: Write coded line. Comdeck COMCWTC. Described 
in UTILITY (2.2). 

dd. itfTW: Write words to working buffer. Comdeck 
COMCWTW. Described in UTILITY (2.2) 

ee. WIX: Write exit. Comdeck COMCWTW. Described in 
UTILITY (2.2) 

ff- Q££: Dump circular buffer. Comdeck COMCWTW. 
Described in UTILITY (2.2). 

99- XJfi: Restore all registers with a system XJR call. 
Restore based on a full word save ar&a (for each 
register). Comdeck COMCXJR. 

hh. ZIB: Zeros to blanks. Comdeck COMCZTB. Described in 
UTILITY (2.2) 

NOTE: Where the comdecks/routines were marked as 
described elsewhere* IDP required the indicated function. 
But at any given time a break may occur in those same 
routines; thus? IDP keeps local copies of the necessary 
routines . 
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2.9 Initialization Routines 
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For each overlay loaded (primary or secondary)? there is a 
corresponding initialization routine. These routines vary 
in size and function, but in each case the initialization 
is performed once? when the overlay is loaded, and then 
the space becomes available for managed table, scratch 
storage, etc. These routines are not true cradle 
<a separate routine exists for each overlay), but, since 
every overlay has one, they appear in the cradle grouping. 
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2-9.1 INITOO: Primary Initialization 

&kSt±£a£±: INITOO provides primary, first time only, 

initialization for FTN5. The initializations 
provided mostly pertain to options present (or 
absent) from the control statement. 

In±2F_£fl£££ ' INITOO interfaces the cells and data 

structures of FTN. It is contained in overlay 
(OfO) and contains the compiler main entry 
point. As such, INITOO is always invoked 
once. After performing the required 

becomes free space. 

a. QQfeEQIE: Installation parameter. Described in 
FTN (2.1). 

b. QQ13CE&C: Several structures are defined for use by 
PAC during control statement parameter processing. 

£ufiLa£±SE._£Ja£Eina : An entokening of the control 
statement parameters. 

K6x-.t£LL_K£ : Parameter table definitions. 

KQa_&E: Multiple binary parameter table 
definitions. 

c &EY.3: Control statement parameter keyword table. 
Expansions of PARAM macro (COMCPAC) in format 
determined by KA. , KB., KC. definitions. 

*• ■ uwx" ntiuo*t> a series ut niuiLif ie uiixary vdiue 

tables. Expansions of MBVOP macro (COMCPAC) in format 
determined by KD. and KE. definitions. 

e. £3-.££lls: Local cells used in processing control 

statement parameters. These provide temps for options 
which require 3-way action. 

*- DiaanflS±i£„l£jt±a : Both PAC and INITOO provide tables 
of diagnostics text and exit addresses. 

g. S&jlZ Code skeleton data definition. Used by ROR. 
Described in FBKEL (3.16). Comdeck COMSEIS. 
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a. ElfcU The system loader entry point. Calls the 
initialization routines and? after determining the 
control statement parameters? either transfers control 
to PUC or calls the overlay loader to load (1?0) 
EQPT=0? MAP or LIST needed! ? (S,0) EOPT>01 or COMPASS 
CIDENT first card! . 

b. £&£? Process arguments from control statement. PAC 
is the control statement cracker. It processes each 
control statement argument in turn, scanning against 
KEYS for legality sf the argument. The corresponding 
KEYS entry is used to test the argument value and 
errors are noted? or the proper cells are set? 
corresponding to the value supplied. In the case of 
multiple binary, the proper MMD table is scanned for 
syntax legality. Any errors noted by PAC result in 
termination of compilation. Comdeck COMCPAC. One 
option of PAC processing is the provision for user 
routines. INITOO provides routines to process the S 
and G options ? and in test mode, the IDP and SNAP 
options. 

c QEL' Check Field Length. CFL determines the current 
field length and* if above the minimum? exits. If 
not? the nominal field length (for the OPT level in 
force) is substituted and a MEM request is made. If 
the MEM cannot be honored? compilation is terminated. 

d. QEU' Change file name. CFN changes the default file 
vector name to that name requested by the control 
statement? or clears the vector if ' file'=0 was 
specified. 

©• u^a« Miscellaneous initializations - A. MIA provides 
initializations which are performed for all 
compilations? regardless of control statement 
parameters. Start time is saved? compiler status 
noted (system vs. library or file)? field length is 
saved? etc. 

"f- fcllB; Miscellaneous initializations - B. MIA does the 
bulk of INITOO initialization. It is called, after the 
control statement has been successfully cracked? and 
resolves irregularities in the control statement 
requests. For some options? the control cell contents 
are converted to compiler usable form. (Some options 
have assembled values in a form which is different 
from the PAC converted form. This is to differentiate 
between a selection of the default value and not 
selecting the value but assuming the default.) All 
dependencies between control statement parameters are 
resolved. Any diagnostics noted by MIA results in 
termination of compilation. 



B-2-39 



g. PPW: Process page width option- The output files' 
TOUTPUT and ERROR) page width is set depending upon 
the PW option status and the output media (printer, 
TTY, terminal, etc.). 

h. CPV: Current parameter values. Converts values of 
selected control statement parameters into display 
information for the header information of listings. 

i- PQA: Find character-address. Utility used in 

processing control statement line for listing header, 



m. 



n, 



J. _ ... 1 - -* « A 

— i i ' \j i 



used in producing control statement line for listing 
header. 

k. STF: Set Terminal File. STF determines if a file is 
assigned to an interactive device. Comdeck COMCBTF. 

1- £01: Global Overlay Initialization. GOI performs 
initialization required by the QCG mode code 
generator. If necessary, the code for map/list is 
trashed. Routines are called to perform front end 
initializations. Comdeck COMFGOI. 

FEI: Front End Initialization. FEI initializes flags 
and switches in front end routines (e.g., ANSI 
diagnostic switch). In (0,0) overlay, a QCG 
function. Comdeck COMFFEI. 

ROR: Reset opcodes of roundables. Depending on the 
status of the ROUND option from the control statement, 
ROR resets the affected code skeletons to 
rounded/unrounded arithmetic. Comdeck COMFROR. 
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INITIO: Reinitialization (GCGX 



JI6 



&fcS±E.a£±: INITIO performs initializations required when 
FTN5 is reloaded after an intermixed COMPASS 
assembly? or when MAP or LIST was required, 
from the initial load. 

IO±£E£a£Sa: INITIO contains the loader entry point for the 
<1*G) overlay. Resides on the (1,0) overlay. 

S£LtS Code skeleton data definition. Comdeck CQf^EIB. 
Described in FSKEL (3.16). 



a. EI&ilQ: The overlay entry point. Calls initialization 
routines and exits to PUC. 

b. QQI: Global Overlay Initialization. Comdeck 
COPFGOI. Described in INITOO (5.9.1). 

c EE1' Front End Initialization. Comdeck COMFFEI . 
Described in INITOO (2.9.1). 

d. BQg: Reset opcodes of roundables. Comdeck CQMFROR. 
Described in INITOO (2.9.1). 
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2.9.3 INIT20: Initialize Primary Overlay (CCG) 

6kS±E.££±: INIT20 performs initializations required when 
the CCG primary overlay is loaded. 

lQi£E.£a > £.££ I INIT50 contains the loader entry point for the 
<2j0) overlay. Resides on the (2 f 0) overlay. 

Qa±a_S±r.U£±ur.£2 

£Q1!E£IE. Comdeck, described in FTN (2.1). 

BfluliQ£-.Q£acxi£±iQna 

ElfcEQ- Entry point for the (2»0) overlay. Entered when 
OPT>0 after INITOO initialization f or upon return from 
intermixed COMPASS ASSEMBLY. Saves initial field length 
and exits to PUC. 
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2-9.4 INIT21: Front End Initialization (CCG) 

&k£±r_a£±: INIT21 performs initializations required by 

the (2*1) overlay? the CCG front end processor 

lQ±£Jl£aiLas " INIT21 contains the loader entry point for the 
(2*1) overlay, 

Sii.l Code skeleton data definition. Comdeck COMSEIS. 
Described in FSKEL (3.16). 



Bau±iii£_Q££cxi£±iai22 

a. ElbEl: The overlay entry point. Calls the 
initialization routines to perform front end 
initializations. Exits to the front end controller. 

b. QLE: Dump link and fill tables. A front end stub for 
read end function. 

c. EEI: Front end initialization. Comdeck COMFFEI . 
Described in INITOO (2.9.1). 

d. BQB: Reset opcodes of roundables. Comdeck COMFRQR. 
Described in INITOO (2.9.1). 
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2.9.5 INIT22: CCG Initialization 
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6kS±C.a£±: INIT22 performs initializations required by 
the common code generator. 

lQ±£Lf dtas : INIT22 contains the loader entry point for the 
<2 ? 2> overlay. 

a. 3ft: Code skeleton data definition. A CCG version of 
the SK. defined for OPT=0. Used by ROR. 

b. IatLlfi-DfifiQiiiflna: Comdecks COMSTAB, COMSTAD and 
COMSTAS. Shared table definitions for CCG used. 
Described in PUC (2.3). 



Bflu±in£_Q£££ni£±iflii£ 

a. EIb££: The overlay entry point. FTN22 performs some 
file management functions and initializes CCG cells. 
The managed table area is restructured for CCG use. 
Exit is to the CCG controller. 

b. BQB: Reset opcodes of roundables. Comdeck COMFROR. 
Described in INITOO (2.9.1) 
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2.9.6 INIT23: Rear End Initialization <CCG) 

6feaiLa£±" INITS3 performs initializations required by 

the (5»3) overlay? the CCG r&ar end processor. 

lQ±£C.£ac.e.s. : INIT53 contains the loader entry point for the 
(5 r 3) overlay. 

Qa±a-.3±i:u£iuiL£s. : Non e 

BQu±in£-DfiS£ni£iifln 

ElfcESZ The overlay entry point. Performs some file 
management functions for the map and listing functions as 
required. Exits to the rear end controller. 
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3.0 FRONI_END_PRgCESS^ 

The FTN5 front end processor consists of decks and routines to 
provide lexical analysis, parsing and intermediate language 
production. A symbol table and other auxiliary tables are 
built. The intermediate language drives both the QCG and CCG 
code generators. 
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3.1 FEC: Front End Controller 



J6 



&kS±La£±: FEC controls processing flow for the front end 

routines. Functions include calling the lexical 
analyzer, transferring to the statement processor 
and inter-statement initialization. FEC also 
contains a number of routines used by the front end 
for various functions. 

In JL£LJu3iLSS. « FEC is the traffic director and controller for the 
front end. Contains program unit and individual 
statement flags and cells. FEC resides on the 
\\jf\jfr \j.f\jf ana \c.f 1 1 overlays. 



Qfilla: 



FEC cells are entries which are used by the 
front end processor. They contain information 
needed by the front end for bookkeeping 
functions. The cells area f in conjunction with 
the managed table area and the program unit cell 
area f define the status of compilation at any 
given point. 



b. E-.SYC3IL: 



Symbol table initialization table. F.SYMIL 
contains the symbol table preset values for the 
compiler generated* fixed ordinal symbol table 
entries. 



c fcteSfcHBL; 



A set of hash buckets, used by the symbol table 
accessing routines. Contained in common block 
/HASH/. 



d. £fc£Bl!i6£i 



CHARMAP is a table used for various purposes. 
It is ordered as the 0. table (described in 

cr-nnrrTv^* / 4 * \ \ -*-i j. _ •_ * _ ^__l *• nnA 

«- n>is i a i u.j.n, me xat?xe consists or uri, 
representation of tokens/operators and a DUC. 
address? where applicable, for use by QCG. 
CHARMAP is used for diagnostic production? QCG 
transposition and some output functions. 



e- EEC=: 



FEC= is the stage vector for the transition 
between the lexical analyzer and the various 
statement processors. The table consists of a 
matrix of current (just entokened) statement 
type by current program unit stage. The entries 
are offsets into the FEC main loop. 
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Routine Descriptions 

a - E|£- Front End Controller. FEC is the front end main 
loop- Upon first entry for the program unit, 
initialization routines are called to set up 
compilation- Thereafter, FEC provides entry points 
for return from the various statement processors and 
stage processors for lexical to syntatic 
transistion. First the statement specific cells are 

nacB'i' +K/airk I CV i *= i- =* 1 1 a. M + n ar.-4- r-.\j mr\ + l-.*a rnppan + 

I cac 14 iticii 1 1 1 r\ Jt. ft kBU icu vu eh mncii bus wv^iiwiiu 

statement- Based upon values returned by LEX, 
pertaining to the type of statement just entokened, 
s» e + = 1 *» yscto' 1 branch is taken to ^rocess the 
statement context. The stage transform routines 
call routines to perform the necessary processing 
where required. If statements appear out of context 
(e.g., type declaration after first declarative), a 
diagnostic is produced. After the stage 
transformation processing is completed, transfer is 
to the relevant statement processor. A special 
return is provided for the END statement. Front end 
processing is completed by a series of subroutines. 
Transfer is to the front end loader to fetch in the 
code generation overlay (CCG) or to transfer to rear 
end processing <QCG). 

b. ASK: Adjust statement keyword. Some of the syntax of 

FORTRAN is 'funny' (i.e., doesn't lend itself to 
lexical analysis nicely). Situations where 
consecutive keywords (implicit type declarations) or 
imbedded keywords (ASSIGN) are present require this 
routine s ASK strips out the 0=VAR token containing 
the relevant keyword of the keyword characters. The 
relevant token is discarded or adjusted (if 
information remains). This adjustment may involve 
retyping a token. 

c. ASL: Adjust Statement Label. Similar to ASK, except that 

a statement label is extracted from the token. Used 
by statements where a label is followed by 
undelimited information (ASSIGN and DO). 

d- QAC: Check assumed character declarations. A front end 

cleanup routine. When character type variables have 
been declared, CAC scans the symbol table to 
determine if any variables have been invalidly 
declared to be of assumed length. 

e - CBN: Check common block names. Searches symbol table for 
non-ANSI usage of common block names. Conflicts are 
diagnosed. Called only when ANSI is specified on 
the control statement. 
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f« CLU: Check Level Usage. A front end cleanup routine. If 
LEVEL was declared, CLU scans the symbol table, 
testing for leveled items being in common or formal 
parameters. Local variables leveled are diagnosed 
and LEVEL formal parameters are marked in the 
symbol table. 

g. yapj tnecK oequente oreaK. uctd x» cesj. j.t-u wrieu a pu^bitue 

IL sequence break can occur. If a sequence break 

hac nrriinraH ^cnKrnii + 'ino i-j» 1 1 _ crano lahelc. 1 nnn 

parse file), the IL is flushed. Action is dependent 
upon the code generation mode. 

h- CUF: Check Undefined Function. A front end cleanup 

routine. CLF determines if a function subprogram 
has been defined. If entry paints of more than one 
type were present, CUF determines that the entries 
were defined. If not, a diagnostic is issued. 

i. CULS Check Undefined Labels. A front end cleanup 

routine. CUL scans the symbol table for undefined 
(but referenced) statement labels. A diagnostic for 
each missing label is output. If the block 
structure table is not empty, its contents ar& 
analyzed and diagnostics for unclosed do loops 
and/or unterminated IF blocks are output. 

j. CUS: Check Upcoming Statement. For control flow 
statements (e.g., GOTO, IF), some front end 
optimizations can be performed if the next statement 
is known. Thus, the concept of the 'hanger' 
processing* When a control transfer statement is 
appended to a logical IF (or an arithmetic IF is 
found), generation of the branch turples is deferred 
until the next statement is entokened. If the next 
statement is labeled, and the label is significant 
(is part of the branch statement), more efficient- 
code can be generated. CUS determines if 'hanger' 
processing is required and, if so, transfers to the 
proper routine for processing. CUS calls CSB for 
sequence break check and determines if a no path 
situation exists, is continued or was terminated. 

k= CVD: Check Variable Dimension irregularities. A front 
end cleanup routine. If variable dimensions were 
declared, CVD scans the symbol table to determine 
that variables used as the adjustable dimensions 
were declared to be common or were formal parameters 
and that arrays with adjustable or assumed 
dimensionality were formal parameters. 
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!• FEP: Front End Presets. FEP is called for each program 
unit to provide initialization of FEC cells and 
tables. 

m - FVP: Flush Variable Dimension code. A front end cleanup 
routine. FVD will take turples, if present, from 
the variable dimension table and move them to the 
parse file. Thus, any code generated for variable 
dimension code will follow the body of code for the 
program unit. 

n- OIL; Output intermediate language. OIL is used to flush 

j t _ _ . _ _ r • » _ i i i _i_ __. i. : i_ _ _ i___ 

t rj«a r\ ~t f> ti at T" i A & « UI1 J> S SS rnga narjgpgr j nil fjaS^t £j {?&?! ! 

supressed, the parse file is flushed, vi& a call to 
PIS. Manner of flushing is code generation 
dependent. 

o. PUP: Program Unit Presets. PUP is called for each 

program unit to initialize PUC cells and tables. 
This initialization could have been placed in PUC, 
but inclusion in FEC allows it to 'go away' when the 
CCG and rear end overlays bp& fetched during CCG 
compilation. 

p. RLS: Relocate local save variables. A front end cleanup 
routine. If variables were declared in a SAVE 
statement, RLS will create a special local block 
'S$A£V$E' in which local save variables will be 
located. This will allow special rear end 
processing of saved variables. The block table is 
updated to include SSASVSE. 

<}• E1Q: Reset intrastatement cells. RSC is called once for 

each FORTRAN statement encountered. It resets 

values of FEC flags and cells which pertain to the 
status of an individual statement. 

r. SSU: Set Save Universal. When an unqualified SAVE was 

declared, SSU will scan the symbol table, inserting 
the save bit in all octal and common variables. A 
front end cleanup routine. 

s. BBC: Base bias conversion. A front end support routine. 
BBC determines the need for the conversion 
(equivalenced variable) and if necessary, replaces 
the operand with one consisting of the base member 
symbol as the ordinal, the offset from the base 
member as the bias and the mode of the original 
operand. 

t. CCT: Check conflicting types. A front end support 

routine. CCT tests a proposed symbol table class 
bit against a list of forbidden classes. If the 
proposed class is forbidden, the DPC for that class 
is determined and used as fill for a diagnostic 
which is output. 



B-3-5 



u. CT1: Construct pass one tag (archaic terminology)- A 

front end support routine. CTi takes a symbol table 
ordinal as input, fetches the corresponding symbol 
table entry and forms a TP. format operand, 
utilizing and transforming the WB. symbol table 
information into TP- information. 

v - STY: Set natural type- STY is called to provide the 

implicit type of defined by usage variables. STY 

I .!..._ t_J I J L. 1 _ „ klAT I r-k I J HAT ^TW« 

lid* LWU dSSUUldLCU IcSUiB* !HM I . L-ELPI ell'Itl INM 1 ■ ITT- 

First, the initial character of the variable (or 
subprogram name) is used as a shift count for a bit 

_i^~.-i. — jl kia-t -rv/o -.-~ ~~~~... »£ u j a. . ._„a._„_ tuj . 

LIIBViR UT I'trt Sell! - - S ! ! S!"!"S T U"!" US.*, VPi !,U!'3: iS!3tS 

determines the implicit type. If the implicit type 
is character, the initial character is used as an 
index into NAT.LEN, a table of implicit character 
lengths- A front end support routine. 

w. TLV: Truncate long variable. A front end support 
routine. TLV is called by various statement 
processors when consecutive variable tokens (O.VAR) 
are encountered. The first token is shifted over 
the last variable token of the string and the token 
buffer pointer is reset. A diagnostic is output. 

x - IB^ : Translate variable. A front end support routine. 
TRV is called when a variable symbol is expected. 
The variable token currently in the token buffer is 
searched for in the symbol table. If not present, 
an entry is made, with the proper variable 
attributes. If a symbol table entry exists, the 
attributes are checked and if an irregularity 
occurred, a diagnostic is output. TRv* returns the 
symbol table WB. entry, a TP. operand and the symbol 
table ordinal of the variable. 

y. TSX: Tag system external. A front end support routine. 
TSX is called to enter the name of a compiler- 
generated subprogram (library routines) into the 
symbol table. Returns the WB. entry, a TP. operand 
and the symbol table ordinal. 

2 - ISY: Tag compiler symbol. TSY is a specialized routine 

which is called to generate symbol table entries for 
certain unique compiler generated symbols. An error- 
results if attempt is made to enter a symbol more 
than once. 
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aa » ERT: Enter Reference Table- A front end support 

routine. ERT is called to format symbol references 
for the cross reference map- If LO=R is not 
specified, the initialization routine for the 
current overlay will wire off ERT. Once the switch 
is set on, a subsequent CS LIST R- directive can set 
or unset the wire off code. Once entered, ERT will 
combine symbol table ordinal, line number and 
current usage into an entry for the cross reference 
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piiy+ ine * 
ESY enters a symbol and its attributes into the 
symbol table. The hash link chain is updated to 
include the new symbol. ESY requires a previous 
call to SSY for linkage (symbol table hash chain) 
reasons. 

cc. INN: Invent New Name. A front end support routine. FTN5 
has several requirements for compiler generated 
names. Some of these ai % s compilation dependent and 
can occur many times during a program unit (e.g., DO 
loop variables and labels). For this class of 
symbol, INN will take a count of the number of 
occurrences of the symbol class, add a prefix and 
make a unique symbol table entry for the compiler 
generated symbol. 

dd. NCM: Enter multiword element into designated table. A 
front end support routine. NCM scans a table 
searching for a match with an arbitrary number of 
words (to be entered in the table). If a match is 
found, the table index of the first word of the 
matching block is returned. If the block is not in 
the table, the necessary space is allocated and the 
block entered. This last is at he caller's 
discretion. (Some applications allocate space, 
build a block and call NCM. If the block was 
redundant, the table is shrunk; otherwise, the data 
is already in place. ) 

ee. SCS: Scan table with supplied mask. SCS searches a given 
table for an entry which matches at only those bits 
denoted by the supplied mask. (As opposed to a 
60 bit match). Comdeck COMFSCS. 

ff. SCI: Scan table comparing all bits. A front end support 
routine. SCT scans a designated table, looking for 
a provided entry. If a match is found, the index of 
the matching entry is returned; otherwise, a miss 
indication is returned. 
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99- SLT: Scan Library Table. SLT scans the intrinsic 
function table (F. INTF) for a function name 
supplied. If the desired function is in F. INTF, 
symbol table attributes are extracted from that 
table and put in WB. and WC. formats. Otherwise, 
the attributes returned are those of a user function. 

hh. SSY: Scan symbol table. A front end support routine. 
"~ SSY accepts the DPC for a symbol and applies the 

r-riir i t. r . l : J . . : — l _l a. L. _ _ . i t u. _ -. L. ..-*!.._ 

r I IN3 nei&ii ruiitiiun tu jra.t-.iy me sjrmuui nasii venue. 

This value is used to scan the relevant hash chain 
to determine if the symbol is present. If present, 

l-V»W I .» L. _ _._.!_ _1 .1 ..L. 1 .« .. ,. J ,' .. . 1 ~_ W 1^+ir-L*, -»», J 

jjg? S'i? i. U>"! jls ii5S STiiiyui %,St?±E" UriiiiiSi guy i i : y e a £S!!%j 

the WB. entry for the symbol. If the symbol is not 
in the table, a pointer to the last link pointer 
(end of chain) is set and an indicator of not in 
table is returned. SSY must be called prior to 
entering any symbol in the symbol table. (Note: 
The hash function used by FTN5 was lifted from FTN4 
which, in turn, used the COMPASS hash function. 
Since COMPASS uses a different alignment for symbols 
[OR vs. 0_3, it is not clear that the current 
algorithm is best for FTN5. If some testing is done 
someday, this could be determined. For now, 
collisions don't seem super rampant, so nothing is 
pressing about this. ) 
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3.2 FERRS: Front End Diagnostic Texts 

6J2S±Lat±: FERRS contains the texts of all diagnostics output 
by the FTN.5 compilers A few diagnostics which may 
occur during rear end processing are included for 
(0,0), (1,0) compatibility. 

ini£H£a£.SLS • FERRS interfaces all decks/routines in the front end 
which issue diagnostics. A diagnostic output 

rnneie+ts n£ a Knanrh 4»n +Ko A 4 n% «*i n js + 4 <- a«4-nw 4-* 

~ w. » — —.,■» — w • mi w • i_> • ■ >. ■ ■ %. w v . • w u^«B9iiVrf=r\.4iW en (.1 7 J.II 

FERRS followed by a branch to the proper formatting 

routine in PEM (5.5). FERRS resides on the (0,0) , 
1 1 .i 

FERRS consists of two main data structures? diagnostic texts and 
dictionary, with associated macros for their generation. 

a. £Q£33SY£- This comdeck provides macros and micros to 

generate literal DPC values associated with 
symbol class attribute bits. The generation of 
the literals is remote. 

b. GQ&6EBEU This comdeck provides the ERROR macro, used to 

format the diagnostic texts. Format for the 
macro is: 

LOG ERROR TYPE, EXIT, (TEXT) 

where 

LQC - diagnostic name and entry point 

TYPE - severity and what type formatting PEM is to 
perform 

EXIT - return address or default return 

TEXT - the actual diagnostic text. 

The error macro will generate the following code: 

LOG SB7 return address 
EQ PEM S 
V 

B depending on the PEM action required 
(the second character in the type 
field, if present). 
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Following the entry code are the words making up the diagnostic 
skeleton- The format is as follows: 



1ST ,WQRP 



L.X t 



CVTT 



+ * 

/ 
/ 

/ 



9 



a^D^fikbiD_suesEQyEbmsiQBDS 




where: 
LIT 



Offset into literal table (dictionary). Note that 
the size of the LIT field limits the dictionary to 
512 entries. Some care in wording new diagnostics 
will keep the dictionary within this range. 

TYPE - The diagnostic severity level. (EL=level) 

EXIT - Diagnostic return address. 

C - Set if further skeleton word(s) exist. 

Di£±ianacJl-.EQIlina±«aQd-EE.fldUi:±iari: Dictionary entries are 
produced by the ERRLIT macro, which counts the number of 
characters in the proposed entry and then blank pads 
(left- justified) and if <10 characters, appends a special 
count character as the 10th character. If the dictionary 
word is exactly 10 characters, nothing is done and if >10 
characters, the 10th character is replaced by blank (55P) to 
indicate continuation and a second dictionary word is formed 
with the remaining characters. 

COMAERR defines the entry points for and ERRLITs of the 
first elements of the dictionary. These include a blank 
word and the FILL, cells. The FILL, cells are preset with 
the literal 'FILL. ! so that the LIT pointers in the 
diagnostic skeletons will be set up properly, but the cells 
are then used for variable information, set by the caller, 
interpreted by PEM. 
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4. Generate a string of tokens for each source statement. 

5- Determine which statement processor is to process each 
statement (i.e. type each statement). 

Figure 3.1 shows the relationship of the scanner to the 
whole. 



* Source lines that are found to be in error in NO LIST mode 
(L=0 f SL=0, or CS LIST NONE) active) are listed by the 
compiler's error processor f PEM (Print Error Message) in 
deck PEM. 

** Alternately, this can be seen as collecting lines into 
groups called statements. 
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FEC 




+ + 



+ + 




+ + 






Fig. 3.1. Simplified front-end master loop with LEX 
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Upon entry? LEX will read? list? and entoken source lines 
until it detects a line that is the beginning of the next 
statement (remember that in FORTRAN , the only way to 
detect end of current statement is to detect beginning of 
next statement). Control then returns to the compiler 
master loop? where the appropriate statement processor is 
invoked to compile the statement. 

This process repeats itself for each source statement 
until the end of the program unit is detected. 



3.3.1.2 Interfaces 



LEX primarily "talks" to the rest of the compiler via its 
data structures. These interfaces are f for the most part, 
predetermined by the FTN 5 overall design? and arm 
inviolate as far as the scanner is concerned. It is hoped 
that by stating these things first, the hows and whys and 
wheres will be easier to understand and criticize. 

This section is divided into 2 sub-sections: INPUTS and 
OUTPUTS. 

a. ibieuis 

Because the scanner is so close to the beginning of 
the compilation process for a source statement, its 
inputs are relatively simple and straightforward. It 
expects some data cells to be initialized (usually 
just cleared), and for the 1st time it is called, it 
expects the INPUT and OUTPUT files to be 
initialized*. In addition, it references a number of 
global flags, most of which contain control card 
information (for example, does the programmer desire a 
source listing, etc.). The I!\FUT file itself is an 

innil+. Kl I + Kor* ai tea +K a e *- =mr-t an m-jr\^na^ i + X j-» >% 
»••!-•«— -w r w-w. v. urvf uau mm wins sbaniisi iiiaf ica 3 <= = At. T'Ul' 

part without interference from the rest of the 
compiler, it is in a slightly different class. See 
figure 3.2. 



* MIB (Miscellaneous Initialization, Part B) in deck INITOO 
sets up the file FETs (or pseudo FETs in a RECORD MANAGER 
world), OPENs the INPUT and OUTPUT files, and performs the 
initial READ to fill the INPUT buffer. 
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Fig. 3.2. Scanner inputs and outputs 
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The scanner's outputs are confined to the listable 
output file? a number of miscellaneous data cells and 
flags? and to three managed tables. Each of these 
managed tables is described below in a somewhat 
general fashion. More detailed information can be 
found in subsequent areas that deal with them. 

This table is the token buffer and is generated for 
each and every source statement. At any one time* 
T.TB only contains the tokened representation of a 
single source statement. This "entokened statement" 
is always preceded by a BOS (beginning of statement) 
token, and is always terminated by an EOS (end of 
statement) token. 

Associated with T.TB are a number of data cells which 
are all related via the common prefix H TB= M . These 
a TB=" cells contain information about the current 
statement in T.TB. 

For example? LEX stores information about which 
statement processor is to compile this statement in 
the cell TB=TYPE. 

The cells TB=In«J v 1. and TB=NUMR are set to contain the 
line number of the 1st line of the statement in T.TB 
(in left and right justified form? respectively). 
This source line number is passed to FTN object 
library subroutines so that if an error is detected, 
the programmer can be informed as to which source line 
is at fault. For SEQ mode input programs, the SEG 
line number is used. 

The cells TB=LABL and TB=LABR (left and right 
justified? again) are set to the statement label (if 
there is one) for the statement in T.TB. 

See the actual definitions in the deck LEX for a more 
thorough description of all the H TB=" cells. 

This table is an auxiliary to T.TB and contains any 
character constant strings that occur in a statement. 
If a character constant does occur? a single character 
constant token will be generated to T.TB. and this 
will point to the actual character string in T.CON. 
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Keeping the actual character strings out of the token 
buffer tends to simplify the parsing and code 
generation of character constants f but is not a 
particularly nacaasac.^ complication of the token 
structure. Its main advantage is that T.CON 
represents a near exact image of what will eventually 
go into the object code for these character 
constants- This means that this data does not need to 
go through any more transformations during the 
compilation? and can be basically copied to the LGO 
binary output file. 

In addition? a simple optimization can be performed 
during generation of T.COM. Redundant character 
constants are ignored via standard table manager 
protocol <i.e. they just aren't put into T.CON if they 
are already there). 



T.CON T.TB 
+ -- -> ABCD 

BOS 



Source Input 
STRING = 'ABCD' 



+ 



variable name 
equal operator 
character constant 
EOS 



Fig. 3.3. Relationship of T.CON to T.TB 
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This table is unconditionally generated for each 
source statement and contains the statement in its 
original packed (i.e. 10 character per word) form. 
Its most obvious use is that of deferred listing 
buffer. If a statement is found to be in error by the 
compiler in NO LIST mode <L=0, St.=0, or CS LIST NONE 
active) , then the statement is unconditionally listed 
from T.STMT by the compiler's error processor , PEM 
(Print Error Message) in deck PEM. 

T.STMT is also used to accumulate source lines at the 
beginning of a program unit that are to be listed? but 
which need to be held until the header statement 
processor has extracted the program unit name from 
T.TB and stuffed it into the source listing title line, 

The two aforementioned uses of T.STMT are not new, 
being performed by the de-f-erred listing buffer in both 
FTN 4 compilers. The third use of T.STMT is new, 
however, and involves the proposed solution to the 
FORMAT problem. It is best shown with an example: 

100 FORMAT 

+ (1) = 2 

The scanner will generate FORMAT tokens for this 
statement, and upon finishing, will query its 
heuristic flags. This will lead to the discovery that 
this is indeed na± a FORMAT statement. The scanner 
now needs to generate normal tokens for this 
replacement statement. Enter T.STMT. The entokener 
has to use T.STMT as its source input because it is 
not practical to try and "back up* the INPUT file to 
the beginning of the statement*. 



*See Design/Executives/TOK and Token Generation. 
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This section is divided into 2 sub-sections. The first 
describes the major functional components of LEX, and the 
second is an introduction to the timing of LEX ' s main loop 
. . . a sort of "what happens when" discussion. 



a. 
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The scanner's main functional components and the name 
of the sub-executive that oversees each component is 
represented in Figure 3.4. 
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Fig. 3.4. LEX's main functional components 



The first 4 components <RNC, CLN, PLR, and TOK) are each 
called once per cycle through the scanner's main loop. 
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LEX is driven strictly on a line by line basis- One 
cycle is made through its main loop for each line 
read, listed? classified*? and entokened. 



IN 



! list 

+ ! 

i + 

! 








+ < + 




Fig. 3.5. Main loop timing - normal 



Figure 3.5 represents the scanner's main loop cycle. IN 
is when FEC calls the scanner. OUT is when the scanner 
classifies a line as being an initial (i.e. end of current 
statement). The OUT path leads to the statement typing 
mechanisms and then back to FEC to invoke the appropriate 
statement processor. 



* Each source line is classified as being one of 5 types: 
initial, continuation, blank, comment, or CS, 



B-3-21 



Figure 3-5 also illustrates a very important scanner 
concept: upon entry at IN* it is assumed that the next 
line to process/entoken has already been read and 
classified- 
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This is true in the general case because this line 
terminated the last statement? but is not true for a few 
important exceptions. The most obvious exception is that 
of the first line of a program unit- This line has to be 
pgsd jjjg^Qpg anything exse can happen- Figure 3*o 
represents an appropriately altered figure 3.5. 



OUT* 
< + 





+ > + 



+ < + 



+ + 

read 



entoken 



.- + 



IN 



Fig. 3-6. Main loop timing - need to read 



This is referred to as the "need to read" case? where the 
scanner has to read before it can do anything. Currently, 
the only two conditions where this is necessary are: 
initializing for the first line of a program unit? and 
after a CS directive has been processed. 



* The OUT path has to be skipped for the 1st cycle through 
the loop. 
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** note ** 



Read-ahead is inhibited when a CS line is encountered to 
assure maximum flexibility, because CS lines can affect 
line handling logic. See 3.3.3-2 CS Statement Processing 



3 . 3 . 2 The Executives 



This sub-section has a separate section for each of the 
e*guuuves udiieu by xne xop-dogr lha. i hey arez 

3.3.2.1 RNC and Reading 

Describes the processes associated with 
reading source lines. This includes a 
discussion of general line format* compressed 
inputr etc. 

3.3.2.2 CLN and Line Classification 

Describes the processes associated with 
determining what kind of line was just read 
(i.e. is the line an initial* continuation, 
comment, null, or CS) . This includes a 
discussion of how SEQ mode input is handled. 

3.3.2.3 PLR and Listing 

Describes the listing logic and its 
relationship to the deferred listing buffer, 
T.STMT. 



Describes the token generator as an 
interpreter of a TOGEL program. 

3.3.2.5 CST and Statement Classification 

Describes the statement typing mechanisms. 
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3.3.2.1 RNC and Reading 



K12 



On operating systems that support CIO* all compiler I/O is 
done via the MACE I/O comdecks. When CIO is not 
available , RECORD MANAGER is used via the FA= comdecks*. 
In either case? RNC (Read Next CardC is the top 
executive. It calls the appropriate low level executive 
(via the READC macro) which will read a single source line 
to the source line image area f CP.CARD**. 



* The FA= comdecks simulate CIO in a RECORD MANAGER 
environment. 

** CP.CARD resides in COMPCOM in the (0,0) overlay (in 
deck FTN). See DATA STRUCTURES/CP.CARD. 
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Fig. 3.7. Read routines hierarchy (CIO) 
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Upon returning from the low level read subroutines* RNC 
assures that each source line is in a standard format. 
Standardizing each source line early in the game 
significantly simplifies line handling logic? for then the 
scanner does not have to have special case code all over 
the place to handle the "non-standard" circumstances, 

A standardized source line has three primary qualities. 
First, it is in its packed (i.e. 10 character per word) 
form. The source line is therefore in a iisJldtLlfi form* so 
that the listing subroutines can list directly from 
CP.CARD. If we are supporting tamac.S5Se.ii input for FTN 5, 
RNC will expand the compressed source line back to its 10 
character per word form. Expanding compressed input might 
seem to be defeating its purpose, but the advantages of 
standardization far outweigh the de-optimization of 
expansion. Compressed input will still be a viable 
optimization for a user because it cuts down the I/O time 
used by reducing operating system requests. Another 
advantage to expanding here is that if the common 
compilers ever get a common (0,0) overlay, RNC could 
reside there, thus doing the job for everyone in exactly 
the same way. 

The second attribute of a standardized line is that it has 
a full zero word EOL* mark. COMCROC returns a source line 
in C format**. Token generation and line handling in 
general can be considerably simplified if they don't have 
to deal with partial words. RNC will space (blank) fill 
the final word of a source line if the EQL mark is not on 
a word boundary. See figure 3.8. There are no kQfiw.Il 
adverse side effects resulting from altering the actual 
source input by blank filling. 



* End of Line. 
** i.e. a source line can have a 12 thru 6€. bit EOL. mark 
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word — > 1 B 3 Kl5 

12- 54 bit + + + 

1 PROG ! RAM MOM : : : 1 

EOL mark + +- + 

! becomes 

+ -~:-+7 — - — + + 

• prog ; ram mom !::::::::::! 
+ + + + 



66 bit + + + + 

! PROG ! ram MOMMA: !::::::::::! 

EOL mark + + + + 

! becomes 

+ + + + 

! PROG ! ram momma !::::::::::! 

+ + + + 



60 bit + • + + + 

! prog ! ram mommas !::::::::::! 

EOL mark + + + + 

(no change) 
Where a ":" represents 6 EOL bits. 

Fig. 3.8. RNC end-of-line formats 



Finally, every full zero word blank line* will be 
converted to a full word of blanks followed by a full zero 
word EOL mark. Performing this simple task takes all the 
grief out of handling these strange blank lines. 



* Now a CDC standard. See DAP S1040. 
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3-3-2.2 CLN and Line Classification 

All pre-entokening line processing is performed under the 
control of a single executive- CLN (Classify Line) is the 
executive and coordinates the following functions: 

1- Statement line number extraction*. 

2. Statement label extraction. 

3. Line classification. 

Line classification involves determining that a source 
line is one of 5 types: 

1. an initial line of a statement. 

2. a continuation line. 

3. a comment line. 

4. a blank (null) line**. 

5. a CS line. 

Normal FORTRAN source lines (i.e. not SEQ) were originally 
designed so that line type could be determined by looking 
at columns 1 and 6. 



* SEQ mode input only. 

** ANSI states that blank or null lines are to be treated as 
comment lines for '76. 
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col 1 is 



Y ! ! N 

— + +-— 



LI 



-i- + + + + + 

! line is ! ! col 6 is ! 



V. W111MICI i l 



Y ! ! N 

j { 

+ + + + 

! i 

+— + + i + + 

! line is ! ! line is ! 

! initial ! ! continuatn! 

+ + + + 



Fig. 3.9. Line typing hierarchy -original FORTRAN 



Time has complicated this simple structure? as is shown in 
figure 3.10. 
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+ + + + + + 

! col 1-2 ! ! col 6 is ! 

! is CS ! 5 blank or 01 

+~+ +--+ +--+ +--+ 

Y ! ! N Y ! ! N 

f— — —— ■*• ^.— — _ _y -f>— .— — -.^. t ==s== -f 

• j i i 

! line is ! ! line is ! ! col 1-72 ! ! line is ! 

! CS ! ! comment ! ! are blank ! ! continuatn! 

+ + +- + +~ + +--+ + + 

Y ! ! N 

+ + + + 

; i 

+ + + + + + 

! line is ! ! line is ! 

iblank(null) ! ! initial ! 

+ -+ + + 



Fig. 3.10. Line typing hierarchy - FTN 5 (non-SEQ) 



The most important difference between figures 3.9 and 3.10 
is that one can no longer merely look at columns 1 and 6. 
EVERY column has to be scanned in order to type a line as 
blank. Consider also that, initially, a blank line 
"looks" like the initial line of a statement*. Now 

n .»«».»« h ~~ 4>u -.4. i^_~* .1 ...4 ^; ..a: -> —-.—..-»— -a. a.u _ j. _ j ^ __ j 
i «ruicriiiu«ri (.not. ii.nc u xa»3 j. t a ua *. a ui i uucui^a a <. tue iaxi enu 

of LEX's main loop**, at a time when the statement in T.TB 
has not yet been compiled. This poses a problem in that 
we have to scan an entire line in order to type a blank 
line, but we don't want to do too much processing because 
looking at individual columns is in the realm of token 
generation. And in the case of an initial line? we don't 
want to generate tokens until the next cycle through the 
compiler master loop, after the current statement at T.TB 
has been compiled. 



i.e. column 6 is blank. Or in SEQ mode, both have a blank 
following the statement line number. 



** See figures 3.5 and 3.6. 
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CLN solves this problem by using the BUB/BUN character Lu 

access method* to strip the blanks that precede the 
statement keyword. 

For example 

100 FORMAT (' HELP 1 ) 

col 16 15 

The blanks in columns 7 thru 14 will be stripped? so that 
the token generator will ksaill at column 15. This means 

_1_L_-1_ J»„._ „ l_ . I *•_ _ »*l MM* • . * »« ■ W * 1 ■ « ■ • 

"T n^a T - ■»• of s, manu ift-ic%- mi m ui i i ctp ^ n »%, i artijg nnn i anA « i. 
■>• • »« ••• 7 » W • *3 >t*ailn «. *• > i CT 7 www 5Ri * +• ju ^ vi *f w^auna un i.<n cnvi wr 

line. CLN can then sense this and properly type the line 
as blank. 

SEQ mode "free form" input is a little different. Line 
number extraction? statement label extraction? line 
typing? and preceding blank strip must be performed 
left-to-right in the correct order. 

Consider the line: 

100 500 FORMAT ( ' YOU ARE GETTING SLEEPY. . . ' ) 

col 14 10 

The line number *1Q0 B is extracted first? then the 
statement label "200"? and finally the blanks in columns 8 
and 9 are stripped. The line is typed as an initial? and 
when FEC reenters LEX to entoken this line? the entokener 
begins at column 10. In this sense? normal FORTRAN lines 
and SEQ mode lines are indistinguishable to the token 
generator**. 

T + uiAct e+a + oH 4 r\ +Ka rmCDUTCLJ eeriinn +Ka+ 4-Ka lima T-iKmRan 

and statement label are stored in the locations 
TB=NUML/TB=NUMR and TB=LABL/TB=LABR. This is not done by 
CLN? however? because it is a low level executive which 
knows nothing about inter-line conditions. CLN stores 
this information into the cells: 

LN=TYPE line type 

LN=NUM line number 

LN=LAB statement label 

* See section (3.3.3.1)? Bub/Bun Character Access Method. 

** This is not entirely true because normal FORTRAN lines are 
75 columns wide? while SEQ mode lines are SO columns wide. 
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The 5 possible line types <i.e. possible values of 
LN=TYPE) are defined by symbols that have the prefix "LT.* 1 : 



value symbol 
1 LT.INIT 
5 LT.CONT 



meaning 
initial line 
continuation line 



3 L=i .uniNi commenx line 

4 LT.NLfcJ. blank or null line 



5 LT.CS 



CS line 



The scanner's main executive? LEX? transfers LN=NUM to 
TB=NUM and LN=LAB to TB=LAB when and if appropriate, and 
acts on LN=TYPEf thus maintaining a clean division of 
labor between detection (CLN) and control (LEX). 



3-5.5-3 PLR and Listing 



Very little has so far been said about listing. This is 
not to say that it is trivial r for many assume that 
listing is one of the scanner's simplest tasks- It is 
not. Few other places in the compiler can match its flag 
chasing abilities or pathologies. Beware . . . 

This section is divided into 7 sub-sections: 

Global Compiler Listing Logic 

Begin at the top. This sub-section describes listing 
at the compiler level* primarily in terms of the 
listing flags. Understanding the listing flags and 
how they interrelate is half the battle. 

PLINE and WOF 

From the top to the bottom. This sub-section 
describes the only common ground in listing besides 
the listing flags: i.e. the low level routines that 
actually write a line. 

Source Listing - Introduction 

The deceptive middle ground. This sub-section 
describes some of the problems and structures involved 
in generating a source listing. 

PLR - Process Listing Request 

Describes LEX ' s executive for source listing. 
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NO LIST Mode 

Describes one of the pathologies associated with 
listing . - . what to list when we're not supposed to 
be listing. 

Before Header Mode 

Another listing pathology . . . how to get the program 
unit name into the title line- 
Deferred Listing File - An Opinion 
Why not clean up this mess once and for all? 

a . £LQBaL-.CQtEIL£S-LISHyQ-.LQfiIC 

Listing logic falls into 2 broad categories: what 
to do when a list option is selected? and what to 
do when a list option is deselected- The various 
list options are selected/deselected via the FTN 
control card and/or the C$ LIST directives. These 
options "translate" into a number of global 
compiler flags. At least this way? when 
confronted with the intricacies of listing, one 
can say, "Well that's because such and such flag 
is set to so and so." Onward . . . 

There are 2 copies of the listing flags: a master 
and a working. The master copy represents the 
list options as selected on the FTN control card* 
and is set up by the control car<i cracker^ . The 
working copy represents the current dynamic list 
options* as possibly altered by CS LIST directives. 



See COMCPAC (Process Arguments from Control Statement) 
in deck INITOO (2.9.1). 
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The working copy is necessary because CS> LIST 
directives are only supposed to affect the program 
unit in which they occur. The master, which reflects 
the FTN control card, is copied to the working at the 
beginning of each program unit, thus destroying the 
effect of any CS> LIST directives that might have 
~ccurred in the ^receding program unit- The master 
copy' resides in deck FTN*in the (0,0) overlay**, and 
the working copy resides in the deck PUC***. 

Following is a brief discussion of the global list 

flags and how they determine/describe the type of 

listing to generate- With the exception of CP.LSTF, 
each flag is a master/working pair. 

CP^LSIF 

This is the master list flag (set via L control card 
option). CP.LSTF has to be ON for most of the list 
options to be able to take effect. The exceptions are 
the error list options. If an error of the requested 
level is detected in a source statement, the statement 
in error is listed along with its appropriate error 
message, regardless of the value of CP.LSTF. If L=0 
is selected, the control card cracker will set CP.LSTF 
to OFF. Then when it has finished cracking the 
control card, it will set all the other list option 
flags (with the exception of the error list flags) 
to OFF. 

WQ-LQS 

This is the source list flag. CO. LOS represents the 
LO=S control card option. The working WO. LOS is 
dynamic and can be affected by C$ LIST directives. If 

WU. LUS IS urr, VlttJH inc wuuip*ici *» *_.-.- -- -- --■ 

NO LIST model- 



** FWA is CO.CS. 
*** FWA is WO.CS. 

£ See 3.3.5.3 PLR and Listing/NO LIST Mode 
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** note ** 17 



If CO. LOS is OFF (i.e. L=0 or LQ=-S selected on the 
control card), then CS LIST directives will be 
prevented from affecting WO. LOS. This is because 
C$ LIST directives are never allowed to override 
options specifically deselected via the control card. 
See 3.3.2 Supporting details/CS Statement 
Processing/LIST directives. 

•iHHt 



IFfW " 1 -^- *« «*«m r* *««• **r ^w a^ruCIure Til© iuy lUdl 

relationship between the lexical scanner (which lists 
source lines in LIST mode) and the compiler's error 
processor (which possibly lists source lines in 
NO LIST mode). The coordination between LIST and 
NO LIST modes is of major concern in listing logic? 
and is discussed further throughout the remainder of 
3.2.3 PLR and Listing. 

b. £LI&JE_£^-M2E 

PLINE (Print Line) is the macro* that is used to write 
a line to the OUTPUT file. This includes lines 
written for the source listing* error messages, 
reference map, object listing, and TEST mode compiler 
debugging output. Each PLINE reference expands into a 
call to WOF (Write Output File). WOF is the only real 
"top-down" executive associated with listing ... a 
call to it will write a single "interesting" line to 
the OUTPUT file with an optional number of preceding 
blank lines. 

Its main functions are to keep track of £a.a£S by 

appropriate times, to output preceding blank lines, 
and to invoke the I/O routines. 

WOF actually writes a source line via the WRITEH 
macro**. WRITEH calls the MACE I/O comdecks on 
operating systems that support CIO, and calls the FA= 
comdecks on operating systems that do not support 
CIO. The FA= comdecks simulate CIO in a RECORD 
MANAGER environment. In a CIO environment, WRITEH 
calls COMCWTH which automatically strips trailing 
blanks from each line kfifflLfi writing it to the OUTPUT 



* Defined in FTN5TXT. 



** Defined in CPUTEXT for CIO (non-RF.CORD MANGLER), and 
in FTN5TXT for RECORD MANAGER. 
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file. This can considerably speed up output at a slow 
speed interactive terminal because then it does not 
have to print any trailing blanks that occur in a 
line. Interactive users rejoice . . . 
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+ + + 
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+ + + 

operating 
system 



Fig, 3.11. Write routines hierarchy - (CTO) 

The reader might find it interesting to compare 
figure 3*11 with figure 3.7. 
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PLINE and WOF? the lowest level executive in listing ? 
are placed here early in the discussion of listing 
because they are really the only £QimSfln element in 
listing . . . everyone calls WOF to write a line to 
the OUTPUT file. It is hoped that PLINE and WOF will 
therefore provide some "home ground" from which to 
embark on the following journeys. 

c - SQLBCEJJLSIltfi-zJLCflBaDUCIiaM* 

Generating a source listing would seem to be one of 
FTN's simplest tasks. In fact, it is one of the most 
complex. The primary reason for this is that so many 
different conditions affect the way a source listing 
will look in its final form. 

For example? did the programmer deselecjt a source 
listing (L=0, LO=-S? or CS LIST NONE active)? What 
this really means is that a source listing is qa± 
generated aulx if there are no errors in the FORTRAN 
program? and this* in turn? depends upon the error 
detection level selected on the FTN control card 
(EL= option). 

CS LIST directives complicate the issue further. If a 
source listing was selected via a control card option? 
CS LIST lines are always listed so that the programmer 
can know where and when her source listing was turned 
on and off*? EXCEPT when a CS LIST NONE line is the 
1st line of a program unit. In this case? nothing is 
listed (unless? of course? there's an error). 

And there there's "before header" mode. Programmers 
like to have the name of the program unit in the title 
line of the listing for each program unit. This means 
that? in LIST mode? the compiler has to delay listing 
everything until the header statement processor 
(PROGRAM? SUBROUTINE, FUNCTION, or BLOCKDATA) has 
processed the header statement and extracted the 
program unit name from the token string (T.TB) and 
placed it into the title line. 

Unfortunately? there is no one "master" control center 
in the compiler that can coordinate/structure all 
these tasks. Individual executives each control their 
own separate (or sometimes not so separate) part of 
the source listing logic. It might be useful to refer 
to figure 3.15 while reading the following sections. 



* See 3.3.3.2? CS Statement Processing/LIST directives. 
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Fig. 3. IS. Source listing routines structure 
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d . ELB-z-EBQCESS J.I3IIfciG-BEaUESI 



PLR is the executive that is called whenever LEX is 
ready to "list" a source line. The word "list" is 
emphasized because the name PLR is somewhat of a 
misnomer. PLR is really not so much concerned with 
listing as it is with freeing up the space occupied by 
a source line at CP.CARD. 

CP.CARD is a dual purpose data structured source 
lines are read into it one-at-a-time and listed from 
it one-at-a-time. The problem is that this simple 

*%^* ft *"S t ■» ^ » ^' .„ .„ ..... _ • .. . f * • » m a_ . . 

"average" case, PLR does control listing, but in 
NO LIST and "before header* modes, PLR doesn't do any 
listing ... it merely saves/accumulates source lines 
in T.STMT. Someone else makes the decision whether or 
not to list the lines at T.STMT. 



RNC 
territory 



PLR 
territory 



one source 



line 



+ + 

INPUT ! 
I 

file ! 

+ 





1 
1 






+■ 


T. 


STMT 


- + 




1 






+- 




A 
i 


-+ 


1 




" + 








i 
















one 


source 


! 






no rAon 






















— r 












line 




1 




1 




- + 








> 




1 


1 






I 










1 

V 












+- 














— T 




1 








OUTPUT 






1 






X. 


f 


ile 





Fig. 3.13. CP.CARD and source line flow 
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Before PLR moves a source line from CP.CARD, it 
performs some line formatting- The two words 
preceding CP.CARD, beginning with CP.FLIN, are used 
for carriage control, compiler generated line number, 
and spacing. 



CP.FLIN 


CP.CARD 




1 


1 ! 


! PROG! RAM ZIP ! 


etc 


carriage 
control 


line 
number 


col 1 of source input 





A line number is generated only in non-SFG mode (SEQ 
lines already have line numbers), and only in the 
following cases: 

in_LISI_ar.-.Ifefi£flr.fi_hfia4fic.l«tDfl4£a 

1. if the line number is a multiple of 5 (1,5,10, 

■ . . etC ) , Or ma. 

2. if the line is a CS LIST line, or . . . 

3. if the contents of CO. SNAP are non-zero in 
TEST mode (for compiler debugging). 

inJ&LLISI-JBQiie. 

1. if the line is an iniiiaJL line of a statement, 
or . . . 

2. if the line number of a continuation line is a 
multiple of 5. 

CS LIST lines are unconditionally given line numbers 
in non-SEQ mode so that the FTN programmer can see 
which lines are missing between a CS LIST NONE line 
and a subsequent CS LIST ALL line. 



e. NQLISE 



In NO LIST mode, FTN always lists source statements 
that are found to be in error along with their 
appropriate error messages, regardless of the source 
list options selected by the programmer. When a 
source statement is found to be in error, PEM (Print 
Error Message) in deck PEM is invoked to issue the 
appropriate error message. 
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In NO LIST mode* PEM is also responsible for listing l " ,u 
the source line in error (which PLR saved in T.STMT) . 
PEM does this by unconditionally calling LDB (List 
Qer&msd Buffer). In addition to listing the contents 
of T.STMT, LDB also takes care of some of the 
bookkeeping associated with T.STMT. For example, it 
prevents the possibility of T.STMT inadvertently 
getting listed twice by querying a status bit in the 
header word of the 1st line in T.STMT. This bit 
(defined by symbols SB.LI8P and SB.LISL ) is set by PLR 
when it puts lines into T.STMT only if they are also 
listed. 

In before header mode* PLR tries to save all source 
lines (including comment lines) in T.STMT* in an 
attempt to allow the header statement processor 
(PROGRAM, SUBROUTINE, FUNCTION, or BLOCKDATA) to place 
the program unit name into the title line of the 
source listing. 

PLR will not save lines forever, though, because for 
programs that have large numbers of comment lines 
immediately preceding or following the header 
statement, T.STMT would soon usurp all of the managed 
table space. In the extreme case, the compiler would 
start "MEMing"* for more managed table space and soon 
usurp the entire machine. PLR will, therefore, only 
save lines while the number of linfiS in T.STMT is less 
than an arbitrary amount (defined by symbol MAX. LINO. 

** note ** 

Using a "line" thresh-hold for T.STMT is different 

+ K jar* +K a 4 mn 1 aman4> a+inn «! *■» a n 4>l% a m !_' I'M A — <i»i>* 1 T j~. «. 
■w. iai ■ kHC *lllf *. WIHC II tia kXWIi 4ii c x li ici c liM T l_ Willi' J. J. *T I" ■ 

They both use a BQnd thresh-hold in determining when 
to terminate "before header" mode. A number of PSR ' s 
have been submitted against FTN 4 by users who did not 
understand why some of their programs got the program 
unit name into the title line and some did not. This 
is largely due to the fact that the number of Unas 
that can occur within a given number of w.Qr_ils. in 
T.STMT is incredibly variable. It is hoped that by 
using a line thresh-hold in FTN 5, it will be easier 
for a user to understand the conditions under which a 
program unit absolutely will get the program unit name 
into the title line of the source listing. 



* FTN "lingo" for making an operating system request for 
more central memory (via MEM RA+1 request). 
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"Before header mode is automatically terminated 
whenever LDB is called. One of LDB ' s main functions 
is to keep NO LIST and "before header" modes from 
stepping on each other's toes. LDB is called when one 
of 5 things happens: 

1. T.STMT becomes longer than MAX.LINC* or . . . 

2. The header statement processor finds the program 
unit name in T.TB and places it into the source 
listing title line* or . . . 

3. FEC (Front-end Controller) senses that this 
program unit doesn't haidfi a header statements 

or ■ » . 

4. A CS> LIST(NONE) line is sensed (i.e. when entering 
NO LIST mode)*, or . . . 

5. An error is detected and control ends up at PEM in 
deck PEM. 

It is perhaps useful to note that "before header" and 
NO LIST modes ars mutually exclusive. That is? you 
can be in one or the other * but not both. 

DEEEBBED«LISIItJG-EILE-.z«^-.QeiblIQfcl 

A deferred listing file is a data structure that 
basically has the format of a T.STMT for an entire 
program unit (or perhaps compilation). Each line in 
it would have a header word that contained information 
about the line. For example* the line type (initial, 
continuation* etc), whether the line was to be listed* 
etc. If a source listing of any kind was selected via 



tue r in! CGiitrul CSvdf <a deferred listing file Would be 

generated. Then at the end of a compilation* it would 
be read back in* interpreted* and a source listing (to 
the OUTPUT file) generated from it. 



* This is necessary to prevent overall confusion in 
pathological listing circumstances. See 3.3.3.5* 
CS Statement Processing* CDDIR, (3.6). 
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Use of a deterred listing file would give the compiler 
±2±al control over the bells and whistles that FTN 
programmers like to have in their source listing. Its 
primary disadvantage is that it slows down a 
compilation due to the added operating system (I/O) 
requests. For this reason? the powers that be opted 
Dfii to use a deferred listing file in FTN 5, even 
though it would considerably simplify listing logic. 
This? I feel, in the long run will prove to be a 
mistake. I do not believe that speed of compilation 
(especially in LIST mode) is as important as the 
simplification of a major internal and external 
structure. 

3.3.2.4 TOK and Token Generation 

This section is divided into 4 sub-sections: 

Overview 

Provides a brief overview of token generation. 

FTN Tokens 

Describes the tokens that can be generated for a FTN 
program. It is hoped that by describing w.ha± TOK is 
trying to do (i.e. its output), that the rest of this 
section will come much easier. 

Learning TOGEL 

This sub-section is basically a tutorial in the 
language of token generation, TOGEL. What it does and 
how to use it. 

Describes/explains the TOGEL program that describes 
FORTRAN. 

TOK - Token Generator 

Describes the inner workings of TOK, and how it 
actually generates tokens. 



LI5 
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TOK is the executive that performs taken generation. 
It is called once per cycle through LEX ' s main loop? 
and entokens a sJLnalg source line. This source line 
resides in T.STMT? and is therefore in a packed 
(10 character per word) format with a full zero word 
EOL mark*. TOK generates tokens f one per central 
memory wordy to the token buf f er . T.TB. 



+ 

i 

! CP.CARD 
i 

+ 






+ + 

P 

L 
R 

+ + 






+ + 

T.STMT 






+— + 

TOGEL 
program 



+ + 

T 
O 
K 

+ + 

A 
i 

— + 






+ + 

T.TB ! 

+ + 

+ + 

T.CHAR ! 



Fig. 3.14. Relationship of PLR to TOK 



* The LEX executive* PLR? will have previously 

transferred the source line from CP.CARD to T.STMT 
See 3.3.2.3 Design/Executives/PLR and Listing/PLR ■ 
Process Listing Request. 
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It is important to remember while looking at "■ ■ 

Figure 3-14 that T.STMT is not a complete? static data 
structure between PLR and TOK. For each cycle through 
LEX ! s main loop, PLR adds a new line to T.STMT. TDK 
is therefore always entokening the las± line put into 
T.STMT. 

TOK is designed to be a general purpose token 
generator. That is* it could just as easily be used 
to generate tokens for PL/I or COBOL as for FTN (this 
assumes ? of course ? that these compilers aan± to 
generate tokens for their source input). This is 
possible because TCK is table driven. Along with the 
actual source line to be entokened? it accepts as its 
input a table that describes hfiw. it is to generate 
tokens. This logic table is generated via a set of 
COMPASS macros that "look" like a simple "top-down" 
programming language. Therefore? these macros are 
called a "language", TOGEL (Token Generation 
Language)? and when these macros are applied to a 
particular token generation problem* the result is 
called a "TOGEL program". 

b. ElfcLIQUEfclS 

This sub-section is concerned with the general "form" 
which tokens can take, and how they structurally 
interrelate. 

FTN5 tokens are a way of representing? or notating? 
FORTRAN source statements. A way that is easier for 
the statement processors to manipulate, and too 
tedious for a human to use. The middle ground. 

The tokens for FTN 5 have been contrived so that they 

a~~--.±w~ eroo-rrjAHi __..___ _4,_j __4,,_ s— -*-*._ i- 

u«r^<-«"Ai/e r- u*r\ i rM-iiM suuilb sidtemgnts in xhe mosi 

fundamental? statement-independent way possible. That 
is to say? so that tokens can be generated with hq 
knowledge of what type of statement (PRINT. GOTO? 
replacement? etc) is being entokened. 

This "mindless entokening" principle means that 
entokening is the process of grouping characters (into 
tokens) that have some simple structural? or 
syntactic? relationship to one another. For example? 
grouping alphanumeric characters into variable names? 
grouping numeric characters into numeric constants? 
grouping character data? and grouping the remaining 
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characters into operators. The structure of FTN's 
individual tokens is very simple. Each token occupies 
a single CM word and has the following general format: 



45 IS 
+ + __ + 

! other stuff ! token type! 
+ + + 



Fig. 3.15. FTN token format 



Where "token type" is an IS bit binary value used to 
distinguish one token from another. This number is 
defined via a symbol that has the prefix "O.", which 
stands for "operator /operand" (for years, I wondered 
what "O." stood for . . .). For example, the BOS 
(Beginning of Statement) token is defined by the 
symbol O.BOS (value = 0)*. 

** note ** 

The lexical scanner can only generate 45 different 
tokens. This is qdJ; a scanner restriction, but a 
restriction imposed by the CONG table which is used by 
the parser , PAR in deck PAR. The CONO table is used 
to check the legality of a particular token following 
another. For example, to detect that in FORTRAN, an 
= token cannot follow a / token. The CONO table has 
only 45 bit positions for token types, ergo only 
thru 41 token types are possible. 

This does not imply, however, that EX£J has only 45 
different tokens. The parser , itself, can generate 
special tokens when it encounters certain syntax. For 
example, PAR will replace the O.LP token that precedes 
a FUNCTION argument list with a O.SLP token. This is 
done to simplify the parsing stack logic. See CONO 
table in deck PAR (B-3.15). 



* "0." symbols are defined in FTN5TXT. 
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The primary virtue of this token structure is its 
simplicity, which happens to make TOK's job relatively 
straightforward- FTlvB tokens take on 3 generally 
different forms. These 3 forms differ both in 
physical layout and in the method in which they arm 
generated. 



M3 



EQBM-JL-IQKEaB_i^B*-CaMSI 






is 
>+ + 

! token type ! 



characters in OL format 



59 



IS 



Currently , the only 2 tokens that are of FORM 1 are 
the variable name token (O.VAR) and the numeric 
constant token (O.CONS) . In this form* the token type 
in bits thru 17 is really only an attribute of the 
characters in bits 59 thru IS. To better understand 
this, first consider which characters can become each 
of these tokens. An O.CONS token can consist of any 
of the characters O thru 9. An O.VAR can consist of 
any of the characters A thru Z and/or O thru 9, but 
the 1st character must be in the range A thru 2. 

In the world of left-to-right scanning then, the 
primary difference between these two token types is 
whether the first character is numeric or alphabetic. 
This is an attribute of the characters that constitute 
the token, which in FORTRAN, happens to distinguish a 
variable name from a numeric constant. 

FORM 1 Examples: 



+• 



— +— 

i 



-+- 
t 

i 
-+ 



i 

«— — """" — """■* — ""* — """"***"" — — — — — — — x — — — — — — T 

+-->! BILBO: : 10.VAR ! 
+ + _ + 



+— 
■>! 1 
+— 
59 







-+ + 

iO.CONS! 

-+ + 

18 



where : is zero fill (OOB) 
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42 IS 

! ! token type ! 

+ + + 

59 18 

FORM 5 tokens are the FORTRAN operators <= - * etc). 
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wiuib in ruru-i x xuKensj xne ongxnai source cnaracxers 
still have "value" , in FORM 2 tokens, they do not. 
The token type itself represents the sum total of the 

processors. Stated more directly, each FORTRAN 
operator has its own token type (0. symbol). 

It is perhaps interesting to note that this need not 
have been so. FORTRAN operators could have been 
represented as FORM 1 tokens, where the token type was 
"operator", and the actual characters that constitute 
the operator occur in bits 59 thru IS. This would, 
however, significantly complicate the work of the 
statement processors, and is not practical in light of 
FTN's overall design. 

LEX does not pass anything of value to the statement 
processors in bits 59 thru IS of FORM 2 tokens. These 
bits are used, however, by the token generator during 
generation of these tokens. Because the token 
generator is extremely table driven, these bits 
contain information set up at assembly-time by the 
TOGEL macros that describe "how" to generate these 
tokens. 

If the reader is making a "first pass" across this 
document- the details of how these bits are used is 
not important at this point in time. For more 
information, see the following subsections entitled, 
Learning TOGEL, and TOK - Token Generator. 
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TWO = ONE + ONE 

+ + « 

+— + + 

i i 

» i + + + 

! + — >! !0.= ! 

! t -r f 

i 

; + + + 

< ' • . <mJ a i ln»VJC? . 
+ + _ + 

59 IS 



+ 

! information 



+— 
59 



18 

-+ + 

! token type i 

- + + 

18 



FORM 3 tokens are the character data tokens? O.CHAR 
and O-HOLL. Bits 59 thru 18 contain information about 
the character data, i.e. the T.CHAR ordinal of the 
actual character string, the number 
characters in the character string, 

FORM 3 examples: 



of words and 
etc*. 



+• 

i 

+ • 
59 



LOWKEY = 



•MISTER* 



// 'GREEN JEANS* 



information 



information 



■ + + 

•O.CHAR! 
+ + 



IO.CHAR! 

-+ + 

18 



* See DESCRIBE/DEFINE definitions of "TB." symbols in 
FTNTEXT for more information about character token 
formats. 
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Let us now consider a few of the more fundamental 
relationships that tokens have between each other in 
the token buffer (T.TB). Consider the statement: 

WAYTQOLQNG = <<A+1>*2> 

The variable name WAYTOQLQNG is way too long for a 
single Q.VAR token? which can only contain up to 7 
characters- 

5 nncaniianr i v . V^A v ' i t l ii i j fj'"^ lvs#~ nma c" 3 •i'give*"* >~ - 
+ + + 

! W A Y T L 5 0.VAR ! 
+ . + + 

+ + + 

! o N G : : : : io.var i 
+ „ ... + _ + 

This means that the statement processors have to be 
smart enough to know that multiple Q.VAR tokens 
represent a single variable name- This "overflowing" 
is only possible in FORM 1 tokens? i-e. with variable 
name (Q.VAR) and numeric constant (Q-CONS) tokens. 

Figure 3.16 shows the entire statement entokened. 



B-3-50 



WAYTOOLOIMG * <<A+1)*20> 

+ + + 

! IO.BQS ! 

+ + + 

1 ! W A Y T L IO.VAR ! 

+ _- + + 

e ! o n G : : : : io.var ? 
+ + + 

3 ! iO. = ! 
+ + + 

4 ! !O.LP ! 

5 ! !O.LP ! 
+ + + 

6 ! A : : : : : : io.var • 
+ + + 

7 ! IO.PLUS! 
+ + + 

S ! i : : : : : : iq.cons! 
+ + + 

S ! !O.RP ? 
+ + + 

10 ! 10.STAR! 
+ . + + 

11 ! 2 o : : : : : io.consi 
+ + + 

12 i !Q.RP ! 

13 ! ! O.EOS ! 
+ + + 



Fig. 3.16- Example of an entokened statement 



Note via figure 3.16 that, in contrast to the double 
O.VAR tokens which represent one variable name, the 
double O.LP tokens (ordinals 4 and 5) will be 
interpreted by the statement processors as being 2 
left parentheses. 

fclEYWQBDS 

No distinction is made between FTN keywords and 
variable names during token generation. Keywords axs 
variable names as far as TOK is concerned. 



M7 
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Consider : 

PRINT 100 

which becomes 

+ + + 

! 10. BOS ! 

+ + + 

i p r i n t i o iq.var ! 

+ + + 

! o : : : : : : io.var « 

4. 4. 4 

! ! O.EOS ! 
+ + + 

The distinction between keyword/variable name and 
between PRINT/100 is made later when the statement 
typing mechanisms are invoked*. This is done to free 
TOK from having to concern itself with FORTRAN'S 
down-right weird keyword syntax. 

Consider the confusion that could arise during token 
generation if all keywords were to be special cased: 



PRINT l,AHm 

vs 
PRINT1 = AHHH 



keyword 
replacement 



IF(YECH) G0T0100 2 keywords 

vs 
IF<YECH)=G0T0100 replacement 

and on? and on, . . 



1 fapwtmg Tnnex 

TOGEL (Token Generation Language) is the set of 
COMPASS macros? or language , if you prefer, for 
describing token generation. Visually, it looks 
somewhat like any one of the glut of popular 
"top-down" programming languages on the market today 



* See 3.3.5.5 Design/Executives/CST and Statement Typing 
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This sub-section is very tutorial in nature. It does 
not discuss how TOGEL works internally (i.e. how TOGEL 
is implemented). If looking for the "hows" of 
implementation, see 3.5.4 Design/Executives/TOK and 
Token Generation/TOK - Token Generator? and see 3.3.3 
Design/Supporting Details/Using COMPASS to Compile 
TOGEL. 

GROUP (0..9) 
Ir i \ HLK / 

CALT XXX 

GROUP <-..) 
£L-5T 



etc 



Fig. 3.17. Sample TOGEL program 



The main difference between TOGEL and all those other 
languages is that you can't do anything with TOGEL but 
generate tokens. It is very specifically oriented to 
the generation of FTN tokens (handy, huh . . .). 

Before diving into the mechanics of haw to use TOGEL* 
one might be interested in the ah* to use TOGEL. Why 
complicate token generation by requiring the learning 
of one more eminently forgettable language? There are 
5 reasons: flexibility (i.e. fixability), and 
conciseness. Token generation is difficult to read 
and understand in COMPASS because it is* by its very 
nature, z&cx. tight code. Consequently, the 
reader-of-code becomes inundated with the details of 

,%*%,•, i *• ■*•*%*.*, -%«* ,4 i ,*..., i ~.i~-\ i **~ i ~ -rrv-Ti .11 -..._ —«._ a._ 

I C»A3 *.CI 3 OIIU 4UW iCVCA * U y .L U a I UUU- OAJ.UW3 UIIC (.U 

take a small step (but a step nonetheless) back so 
that one can see all the logic of token generation in 
a single eyeful. In this way, it is easier for a 
human to critically analyze the problems of token 
generation, and to solve them at a sufficiently high 
enough level that they will remain solved (i.e. not 
just buried) . 

TOGEL does not pretend to be complex or esoteric. It 
is v.fiE.Z simple. TOGEL "instructions" are "executed" 
sequentially in the fashion that all programmers are 
familiar with. In fact, each TOGEL instruction/macro 
CfiUld be replaced with actual COMPASS instructions 
(although they're not, primarily for space-efficiency 
reasons) . 
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TOGEL has one verb: GROLF? a number of flow control 
mechanisms: IFT? ELST? ENDT? CALT? and GOTO? and the 
special entokening mechanism: CASEOF? TOKEN? and 
ENDC. The remainder of this sub-section discusses 
each of these "instructions" in detail. 

QRQUE 

The GROUP verb can be thought of as a character 
function. rhe basic idea behind it is the ability to 
"group" consecutive characters in a left-to-right 
scan. The characters* or range of characters? that 

■ at* •■_ U U _ — . . 

wan w*.wu« n* viij.il is f«f <.4.t.uxai 31 uup are sKCuirieu as 

an argument in the GROUP verb. 

Consider a line consisting of the characters 

AABAAACBD 

First? an invisible? internal pointer is set to the 
beginning-of-line (i.e. to the 1st character in the 
line) . 

AABAAACBD 



WHO 



The command 

GROUP (A) 
which reads? "group all the A characters"? produces: 
group # contents source line 



AA 



AABAACBD 



Now the command 

GROUP <AB) 

which reads? "group all the A and B characters"? 
produces: 



group # 


contents 


source line 


1 


AA 


AABAAACBD 


2 


BAAA 


AABAAACBD 
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Alternately* given: 
AABAAACBD 



flM 



the command: 

GROUP (A..C) 
which reads? "group the characters A thru C" ? produces: 
group # contents source line 



AABAAACB 



AABAAACBD 



The 2 characters .. are interpreted as indicating a 
range of characters. 

For example 

GROUP (A..CK..N) 

is readt "group the characters A thru C, and K thru N 
(i.e. ABCKLMN)". Character ranges are circular? that 
is 

GROUP ( ?:a> 

is equal to 

GROUP ( ..A) 

In addition, the . . operator has a default range. If 
the "from" operand is missing, its default is the 1st 

~ W -.- i— A — ~ - — iU. ~U._.__~.X __J- •» a a I ir J. I »J._H 

tiiai auier xu utic twai ac ier scri, • , emu XT trie to 

operand is missing, its default is the last character 
in the character set, 



u » a 
f • 



Therefore: 



GROUP < . . Z > 
GROUP (A..) 
GROUP <„.) 



equals 
equals 
equals 



GROUP ( : . . Z ) 
GROUP (A..?) 

group ( : ... ; ) 



Besides the .. operator, TOGEL has another special 
operator. If a - character occurs as the first 
character in a GROUP specification, then the finiina 
specification is logically negated. 
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For example lWl£ 

GROUP (-AB) 

reads, "group everything b_u± A and R H , which is 
equivalent to 

GROUP (C.-:) 

i he Gkuuk command can also be invoked with or without 
blank squeeze- If the NSGZ option/parameter is 
specified, *hen blanks (55B) will not be ignored 

* v**_Taw,* t a.S Oct*. , jluS» Ui.auK3 isiiursu/ . 

For example, given: 

A B C D 
the statement 

GROUP (A..C),,SQZ 

would produce: 

group # contents source line 

1 ABC A B C D 

i 

While the statement 

GROUP <A..C),,NSGZ 

would produce: 

group # contents source line 

1 A A B C D 

i 

Now consider the statement: 

THE=COW=JUMPED=OVER=THE=MOON 

Keeping the structure and format of FTN tokens in 
mind, it can be seen that it is desirable to "group H 
these characters in the following manner: 
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characters/groups 
THE 
COW 

JUMPED 
OVER 
THE 



tokens 

O.VAR 

O. EQUAL 

O.VAR 

0. EQUAL 

O.VAR 

O. EQUAL 

O.VAR 

□.EQUAL 

O.VAR 

0. EQUAL 

G.VAR 
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variable name 
equal operator 
variable name 
equal operator 
variable name 
equal operator 
variable name 
equal operator 
variable name 
equal operator 
variable name 



This can be performed with the following TOGEL program: 







group # 


contents 


GROUP 


(A..Z) 


1 


THE 


GROUP 


( = ) 


2 


= 


GROUP 


(A..Z) 


3 


COW 


GROUP 


< = ) 


4 


5= 


GROUP 


(A..Z) 


5 


JUMPED 


GROUP 


( = ) 


6 


= 


GROUP 


(A..Z) 


7 


OVER 


GROUP 


( = ) 


8 


= 


GROUP 


(A..Z) 


9 


THE 


GROUP 


( = ) 


10 


= 


GROUP 


(A..Z) 


11 


MOON 



which can be optimized as follows: 

LOOP GROUP (A..Z) 
GROUP (=) 
GOTO LOOP 

It is pretty easy to see that, in FTN5- each GROUP 
group is destined to become a token. As each source 
line is scanned from lef t-to-r ight * characters are 
built into groups that become tokens- So. in general* 
a single type of token is generated for each 
"execution" of the verb GROUP. 
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** not© ** 



A distinction is made here between "a single type of 
token" and S! a single token". A single type of token 
may consist of more than one consecutive token (i.e. 
consist of more than one CM word)? all of which will 
have the same token type (i.e. "0." value in bits 
thru 17). 

Also? the words "in general" are used because there 
are exceptions to the rule in FORTRAN, particularly 
when dealing with tricky syntactic tokens such as the 
Mf l.j or H character data representations. 

### 

The token type (0. symbol) that a GROUP group is to 
have can be specified as the 2nd parameter on the 
GROUP command/macro: 

GROUP (0.. 9), CONS 

If a token type is specified? the bits thru 17 of 
the token to generate will contain the token type 
(Q.CONS in the above example). Bits 59 thru IS will 
contain the "grouped" characters*. 

EL!^-QQblIBQL-z>IEIx-.ELSIx-^blD-.ablDI 

TOGEL is intended to be used as a block structured 
language? where the IFT? ELBT? and ENDT mechanisms 
work in the usual manner (the suffix T is used to 
avoid conflicts with the COMPASS pseudo-ops). 

IFT is used to test the character that terminated the 
most recent GROUP group. 



* See previous sub-section entitled FTN Tokens for a 
description of FTN's tokens. 
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Fop exampler given: 
BYE = YALL 
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then the command: 

GROUP <A..Z> 
pr oduc 85" 

group # 
1 



contents 
BYE 



source line 
BYE = YALL 



The *=" character terminated the GROUP (A..Z). This 
character can now be tested for via the I FT command: 

IFT (=) 

or perhaps via the more general: 

IFT <+..:) 

where the character or range of characters to test for 
is specified. IFT character ranges have the same 
syntax as GROUP character ranges? and the following 
THEN-ELST-ENDT block ranges are conditionally 
"executed" in the appropriate manner. 

Consider the 2 different source lines: 



BYE = YALL 



BYE 153 



The following TOGEL program allows the programmer to 
do one of two things: 

line 1 GROUP (A..Z) 

5 IFT (=) 

3 GROUP < - . . ) 

4 GROUP (A..Z) 

5 ELST 

6 GROUP (0..9) 

7 ENDT 
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For BYE = YALL: 






group 


# 


contents 


source line 


1 




BYE 


BYE = YALL 


a 




- 


BYE = YALL 


3 




YALL 


BYE = YALL 


Or for BYE123! 


i 






group 


# 


contents 


source line 


i 




BYE 


BYE 123 


2 




123 


BYE123 



MI6 



Concerning the c 
of the preceding 
internal timing 
the GROUP comman 
character . Ther 
not everything ( 
contains only on 
this is to consi 
GROUP group <tes 
character of the 



** note ** 

haracter range in GROUP <-..)? line 3 
TOGEL program: Because of the 
involved with "grouping" characters? 
d aJLwa^S forms a group of at least one 
efore GROUP <-.«), which reads? "group 
i.e. nothing)" , forms a group that 
e character. Another way to look at 
der that a character that terminates a 
table via IFT) a.l&a.££ becomes the 1st 
next GROUP group. 



This inconsistency exists for efficiency (i.e. speed) 
reasons. The GROUP processor does not want to have to 
test for the null group before "grouping". This can 
be considered similar to the zero trip DO loop problem 
in FORTRAN. See Design/Executives/TOK and Token 
Generation/TOK - Token Generator. 

»** 

The first of these two instructions is pretty 
self-explanatory. GOTO will transfer control to the 
specified label within a TOGEL program. 

For example; 

LABEL GROUP (A..C) 

m 
s 

GOTO LABEL 
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The CALT instruction is used to invoke special user 
code when situations arise where the programmer wants 
or has to use COMPASS to get the .job done. 

Fop example: 

CALT PUPPIES 

will force the token generator to suspend "reading" 
TOGEL instructions and transfer control of the CPU to 
the address PUPPIES- When the programmer's own code 
is finished doing whatever , it should transfer control 
to TOK s r1N. This will return control back to the token 
generator and the TOGEL program in progress. 

For example: 

GROUP (0..9) 
IFT (HLR) 

CALT TOK=HLR 

GROUP (..),, NSQZ 
ELST 

m 

etc 

This TOGEL could be used to process the H, L f or R 
data representations which use an explicit character 
count, as in: 13HHELLO. . .HELLO. The code at TOK=HLR 
will convert the previously entokened character count 
< 13 in our example) to binary, and then "dink" up 
TOK's pointers so that the GROUP (..),, NSG7 will group 
the appropriate characters ( KELLO ... HELLO in our 
example) . 

Registers are v.£r_£ tight in TOK and it is the CALT 
user's responsibility to make sure critical registers 
don't unwittingly get clobbered. Be careful. 

COMCTOK contains 5 utility subroutines that can help 
alleviate some of the "tight register" problem. They 
are: SER (Save Entokening Registers) and RER (Restore 
Entokening Registers). It is probably a good practice 
to use SER and RER for all CALT user owncodes. It is 
IMPORTANT to note, however, that SER and RER do NOT 
save and restore register AS (next address to store a 
token). This is due to the fact that it is not always 
possible to tell whether the "next token to store" is 
at (AG) or (AS+1). See SER and RER in COMCTOK. 



m 
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These instructions are used together and essentially 
define a character map technique for generating 
certain tokens (usually simple operators) as quickly 
as possible. 

Their structure is as follows: 

CASEOF (Cl..Cn> 

TOKEN token type 1 
TOKEN token type B 



TOKEN token type n-1 
TCKEN token type n 
ENDC 

where CASEOF and ENDC define the boundaries of the 
character map 9 and each TOKEN reference defines a 
token which can be potentially copied to the token 
buffer . 

It works like this. . . First? the CASFOF statement 
contains a range of characters (Cl..Cn) that specifies 
the first and last characters in the character map to 
follow. When the CASEOF statement is encountered in a 
TOGEL program? the binary value of the character that 
TOK is pointing to is biased by CI and then used as an 
ordinal into the character map. That character map 
(TOKEN) entry contains a skeleton token which is 
picked up and copied to the token buffer. Voila . . . 
a token is born. The token type (O. symbol) that 
defines each token in the character map is specified 
as a parameter on each TCKEN instruction/macro. 

Consider the following pictorial representation of how 
CASEOF-TOKEN-ENDC works for a particular example: 



B-3-S2 



CHARACTER *4 HELLS, BELLS 






A 
i 




H3 


+ 








— — — — — — — — — ^- 


V V 






* + 






47B - 45B = 2 


CASEOF (+...) 


! 45B+0 


TOKEN 


PLUS 


! +1 


TOKEN 


MINUS 


+ — > t5 


TOKEN 


STAR 


+3 


TOKEN 


SI-ASH 


+4 


TOKEN 


LP 


+5 


TOKEN 


RP 


+6 


TOKEN 


DOLLR 


+7 


TOKEN 


EQUAL 


+ 10B 


TOKEN 


BLANK 


+ 11B 


TOKEN 


COMMA 


+ 12B 


TOKEN 
ENDC 


PERIOD 








i 
V 






j._— -.__ — ___.__ 






! O.STAR tok 


en ! 




! copied to 






! token buff 


er ! 




! (T.TB) 







rig 



i ra 



example or twatup- 1 unc.fN-c.fMLA- cnar map 
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Now consider: 



LOOP 


GROUP <A..Z),VAR 
CASEOF (+...) 




45 


TOKEN PLUS 


f 


46 


TOKEN MINUS 


- 


47 


TOKEN STAR 


* 


50 


TOKEN SLASH 


/ 


51 


TOKEN LP 


( 


52 


TOKEN RP 


) 


53 


TOKEN DOLLR 


S 


54 


TOKEN EQUAL 


= 


55 


lUKEN BLANK 




56 


TOKEN COMMA 


r 


57 


TOKEN PERIOD 
EhDC 
GOTO LOOP 


* 
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Fig. 3.18. TOGEL example 

which could be used to entoken a hypothetical language 
that consisted of alternating variable names and 
simple? single character operators. 

Consider a statement in such a language: 

ALEPH = BETH + GIMEL 

The TOGEL in figure 3.18 would produce the following 
tokens: 

ALEPH * BETH + GIMEL 






O.VAR - 
0. EQUAL- 
O.VAR - 
O.PLUS - 
O.VAR - 
O.EOS ■ 



--+- 



— +— 



The O.BOS and O.EOS tokens are always invisibly 
generated and act as delimiters for the entokened 
statement. 



B-3-64 



N5 

The CASECF, TOKEN? ENDC mechanism always advances 
TOK ' s internal pointer that points to the next 
character in the source line. 

For example, given: 

ALEPH = BETH + GIME3- 
i 

then the statements : 

CASEOF £+._-•>_ 
TOKEN PLUS 



TOKEN POINT 
ENDC 

generate an O. EQUAL token, and result in: 

ALEPH = BETH + GIMEL 



Our simple language of variable names and single 
character operators can now be expanded to: 

LOOP 



I FT (+...) 




THEN 




CASEOF (+...) 




TOKEN PLUS 


+ 


TOKEN MINUS 


- 


TOKEN STAR 


* 


TOKEN SLASH 


/ 


TOKEN LP 


( 


TOKEN RP 


) 


tth/etki r\r»i i a 




TOKEN EGrtJAL 


S 


TOKEN BLANK 




TOKEN COMMA 


f 


TOKEN PERIOD 


u 


ENDC 




ELST 




GROUP <A..Z),VAR 




ENDT 




GOTO LOOP 





which entokens syntaxes involving consecutive single 
character operators, such as in: 
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H6 



MANAGERS = ( GOOD ) + ( BAD ) 






O.BOS — + 

O.VAR 

O. EQUAL 



--+- 
i 



U-LT 

O.VAR — 
O.RP 
O.PLUS - 






- + - 



O.LP 



O.VAR 



O.RP 



O.EOS 



Now suppose our hypothetical language is to have 
multiple character operators? such as ** 
exponentiation. This can be encoded in TOGEL via a 
2nd parameter on the TOKEN instruction/macro. This 
5nd parameter is used to describe multiple character 
operators in terms of other ifikans. Emphasize ifiksna 

For example* to describe ** exponentiation? use: 

CASEOF (+...) 

I UTS.CJM rLUO T 

TOKEN MINUS 

TOKEN STAR * 

TOKEN EXP , ( STAR , STAR ) ** 

TOKEN SLASH / 



ENDC 

This TOGEL states that the O.EXP token is defined to 
be 2 consecutive O.STAR tokens. 
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** note ** "' 

Understanding why multiple character operators are 
described in terms of iflkans and not cJiacaciaLs 
requires some knowledge of the internal 
workings/philosophy of TOK. For more information, see 
Background/Problems and Solutions/Multiple Character 
Operators , and see Design/Executives/TOK and Token 
Generation/TOK - Token Generator. 

In any case, I do not believe that this is the 
appropriate place to delve into this subject. Please 
merely accspt for the time being that describing 
multiple character operators in terms of other tokens 
is the mast desirable (i.e. optimal) approach to this 
problem. 

*** 

Some multiple character operators cannot be fully 
described in terms of other tokens. For example? 
consider the boolean operators .AND. and .OR., which 
both consist of the tokens O. PERIOD, O.VAR, 0. PERIOD. 
The critical difference is the characters that 
constitute the O.VAR tokens. The TOKEN macro has a 
special syntax for these fellows: 

CASEOF (+...) 
TOKEN PLUS 



TOKEN PERIOD 

TOKEN AND, (PERIOD, VAR' AND', PERIOD) 
TOKEN OR, (PERIOD, VAR* OR* , PERIOD) 
ENDC 

where the actual characters to check for are enclosed 
in (' '). 

Specifying the actual character string check via the 
<") syntax is only meaningful when used with FORM 1 
tokens*. If used with FORM 2 or FORM 3 tokens, 
unpredictable, or rather, unusual results can be 
expected. Don't do it. 



* See the previous sub-section entitled FTN Tokens for a 
description of FORM 1, S and 3 tokens. 
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TOK is the executive for token generation? and exists 
as a common comdeck? COMCTOK. It accepts as its input 
a source line to entoken* and a table generated at 
assembly time by the TOGEL macros* that describes £lQ& 
to entoken. If one thinks of TOGEL as a pseudo 
compiler (written in COMPASS* s macro language) f then 
this table can be thought of as TOGEL' s "object 
module* 5 ? called TOM for short. 

Each TOM consists of a sequence of binary TOGEL 

inauui.(.ii3iiS Xnax uSR &b ejetuteg oy tun, tacn 

binary TOGEL instruction occupies a single CM word and 
has the following general format: 



N8 



42 

other stuff 



IS 



opcode ! 
+ 



59 



IS 



Fig. 3.19. TOGEL binary instruction format 

A typical TOM, therefore? would take the form: 

45 IS 
+ + + 

word ! ! opcode ! 
+ + + 

1 ! ! opcode ! 
+ + + 

2 ! ! opcode ! 

f + + 

m 
m 

+ + + 

n-1 ! ! opcode ! 
+ + + 

n ! ! opcode ! 
+ + + 

59 IS O 

Fig. 3.20. TOGEL object module (TOM) format 



* TOGEL macros exist in comdeck COMATOK. See previous 
sub-sections in this section? 3.2.3 

Design/Executives/TOK and TOKEN Generation, for more 
information about TOGEL. 
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TOK will step through the TOM it was given? 
"executing" each binary TOGEL instruction as 
encountered. 



N9 



it is 



TOK can therefore be thought of as a machine that 
executes binary TOGEL instructions from a TOM 
conceptually much in the same fashion that a hardware 
CPU executes a program object module- In "da bizniz", 
a software program that performs in this way is 
generally called an iu.Xe.r.P.r.etfin. . 

TOK is structured with a main driver, TOK=MN y 

aui i WuuUgu E? 7 T«Fiw *. J. una a uiu 13 \ I ulTtJ^ / WM i V. II uO IHUS t 

of the work. TOK^m acts as a focal point during 
token generation* and is responsible for reading 
instructions from TOM and farming each one out to its 
appropriate TOFU. TOFUs are totally independent of 
one another: there is one TOFU for each binary TOGEL 
instruction that the TOGEL macros can generate. 



GROUP 
(SQZ) 



A 

I 



TOM 




IFT 




+ 

i 

GROUP ! 

(NSQ7) ! 

+ 

A 
i 

— + 



i 
V 



CALT 



Fig. 3.51. TOK's structure , showing TOFUs 

After a TOFU has performed its specific task, it will 
return control back to TOK=MN so that the next 
"instruction" can be "read" from TOM. This process of 
"reading" and "interpreting" continues until the 
entire source line has been entokened, at which time 
TOK returns control back to the caller. 
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** note ** 

Only 6 binary TQGEL instructions . . . what happened 
to ELST-ENDT, and TOKEN and ENDC? The ELST-ENDT 
structure gets converted by the TOGEL macros into 
GOTOs in the normal way (i.e. via the standard 
compiler cop out). 

For example: 
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IFT 


CA..Z) 
GROUP (A..Z) 






El__5" 


GROUP <0..9> 






EJNDT 






becomes 


b 










T 


F 




IFT (A..Z) 


— + 
i 


— + 




GROUP (A..Z) 


<-+ 






GOTO .2 






.1 


GROUP <0..9) 


/— __. 


___ j. 




T 


.2 


etc 







The ENDC macro is merely used to force assembly of its 
preceding TOKEN macros (i.e. it is required because of 
the way the macros work). It generates no code- See 
3.3.3 Design/Supporting Details/Using COMPASS to 
Compile TOGEL. 

The TOKEN macro does generate "code" to the TOM, that 

J— ________-l /..__-! u.. .l. u. _ y>»A rrnr ffw i i t _ e _ _ a. -»«i-m / r—k i 

as KiuuBsseu/useu i?y uie uftbcur iutu. m rictf i unruN 

can be thought of as a sub-structure of the CASEOF 
instruction. See the sub-sub-section in this 
sub-section entitled, TOK=COF - CASEOF Instruction. 

**# 

In the interest of clarity, and at the risk of being 
redundant, I would like to emphasize that binary TOGEL 
instructions specify operations that are to be 
performed kz TOK ueaq the input source line. In a 
crude sort of way, they represent the nul&s that are 
to be used to translate/convert any input source line 
from its packed (10 character per word) form to its 
entokened form. 
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TOK works very closely with the BU3/BUN character 
access method which is used to make the actual 
character accesses upon the input source line. In the 
"lingo" of TOGEL? these routines are capable of 
GROUPing characters in an entokenable form, TDK's 
various TOFUs will call BUB and/or BUN when they need 
characters from the input source line. BUB and BUN f 
therefore* are slaves to TOK ' s various TOFUs? which 
are in turn* slaves to the TOM driving them. 



Mil 



+ 

I 

i 
+ + + 



! TOM ! 
I i 

i 
i 

+ + + 

TOK=MN ! 

i 

+ + + 

I 

t 
+ 



TOFUs 



• « « 



+ + 

i 



+ + + 



+ + 

i 



+ + + 

i 

BUB /BUN ! 
I 

+ 



Fig. 3.25. Entokening routines hierarchy 
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ItflSUfiL-EQIUIEBSZBEGISIEBS 

TQK has a set of global internal pointers that 
describe whgr_S it is entokening (i.e. where we are in 
the input source line)? teibfins it is entokening to 
(i.e. somewhere in T.TB), and wiifiiie. it is in the TOM 
that is running the show. 

These pointers are kept in registers whenever 
possible, and are saved in memory when necessary. 
These pointers are the reason that TOK is so tight on 
registers. Registers are used as much and as long as 
possible so that TOK will run as fast as possible. 

A COMCTOK caller provides a parameter list? called 
TOKCQM (TDK communications area) 9 that contains the 
initial values of these internal pointers/registers. 
One of the first things TOK does is to transfer 
appropriate TOKCOM entries into TOK ' s global 
registers. During the entokening of a source line. 
TOKCOM is used as a place to dynamically 
materialize/save these global registers when 
necessary. Registers are materialized/saved in TOKCOM 
when either registers get too tight to get the job 
done? or if COMCTOK is running in TEST (i.e. debug) 
mode. In TEST mode, TOKCOM is updated in TOK ' s main 
loop, TOK=MN, before evetY, TOGEL "instruction" is 
executed. This feature can provide an "audit trail" 
that can be useful in debugging. 

Because TOK has a dissociated internal structure (i.e. 
TQRJ's are invoked independently of one another, based 
entirely on what is in the TOM being 
executed/interpreted), these internal pointers 
constitute 

Most of TOK*s global pointers/registers are also 
BUB/BUN global registers (i.e. COMCTOK and 
COMCBU8/COMCBUN work hand- in-hand very closely, and 
share common registers). 

The only register that is unique to TOK (i.e. BUB/BUN 
don't know anything about it, except that they must 
leave it alone) is AO. Register AO is TOK ' s pseudo P 
register. It points to the next binary TOGEL 
instruction to execute in TOM. Therefore, when within 
a particular TOFU, the instruction baina. 
executed/interpreted is at AO-1. 
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